Я на самом деле работаю в подобной системе, поэтому меня интересуют ответы, которые вы получите.
Для моего проекта наличие полного исторического учета не имело значения, поэтому мы решили держать таблицу довольно скудной, как и вы. Наши таблицы выглядят примерно так:
CREATE TABLE `activity_log_entry` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`event` varchar(50) NOT NULL,
`subject` text,
`publisher_id` bigint(20) NOT NULL,
`created_at` datetime NOT NULL,
`expires_at` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `event_log_entry_action_idx` (`action`),
KEY `event_log_entry_publisher_id_idx` (`publisher_id`),
CONSTRAINT `event_log_entry_publisher_id_user_id`
FOREIGN KEY (`publisher_id`)
REFERENCES `user` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8
Мы решили, что не хотим хранить историю навсегда, поэтому у нас будет cron задание, которое убивает историю после определенного периода времени. У нас есть столбцы created_at и expired_at просто из-за удобства. Когда событие регистрируется, эти столбцы автоматически обновляются моделью, и мы используем простую strftime('%F %T', strtotime($expr)), где $expr - строка, подобная '+30 days', которую мы извлекаем из конфигурации.
Наш столбец subject похож на ваш callback. Мы также решили не связывать тему действия с другими таблицами напрямую, поскольку существует вероятность того, что не у всех субъектов событий будет таблица, кроме того, даже не важно сохранять это отношение, поскольку единственное, что мы делаем с этим журналом событий, это отображать сообщения фида активности. Мы храним объект сериализованного значения данных, относящихся к событию, для использования в предопределенных шаблонах сообщений. Мы также напрямую кодируем, к какому событию относится (например, профиль, комментарий, статус и т. Д.).
Наши events (иначе действия) являются простыми строками, такими как 'update', 'create' и т. Д. Они используются в некоторых запросах и, конечно, помогают определить, какое сообщение показывать пользователю.
Мы все еще находимся на ранних стадиях, так что это может немного измениться (возможно, основываясь на комментариях и ответах на этот вопрос), но с учетом наших требований это показалось хорошим подходом.