Дизайн шаблона хорош для истории многих организаций?

В моем приложении есть классы сущностей. Я хочу сохранить все изменения в этих объектах, а некоторые события произошли в таблице истории. Проблема в том, что классы сущностей различны, строятся с разными примитивами и отличаются между ними.

Например, в приложении для покупок могут быть: Пользователь, Элемент, Сделка, Часы. Я хочу, чтобы у вас был возможность показать журнал активности для пользователя следующим образом:

16:00 Вы купили "Властелин Колец" в транзакции 2468,
15:30 Вы добавили "Хоббит" в список наблюдения,
15:00 Просмотренный товар "Сильмариллион" снизился с 15 до 12,50 евро,
14:30 Вы изменили свое имя от "Tomasz" до "Tom".

В этом журнале есть много вещей:

новый объект 2468 транзакции с элементом "LotR",
новый элемент наблюдения, связанный с элементом "Хоббит" и моей учетной записью,
обновленная цена товара (но хранятся как старые, так и новые цены),
обновленное имя пользователя (как старые, так и новые).

Мой главный вопрос - как отслеживать эти данные?

Должен ли я иметь столько таблиц, сколько таблиц сущностей, чтобы сохранить их изменения? UserVersions, ItemVersions и т.д.
Должен ли я запрашивать все таблицы версий, объединять и сортировать результаты для создания этого журнала?
Или, может быть, должна быть одна таблица версий с колонками "Entity", "OldValue", "NewValue" - как насчет ограничений и внешних ключей? Разве это не грязное решение?
Есть ли шаблон дизайна для этого?
Наконец, если вы знаете - как это делает Facebook?:)

Ответ 1

Вам может быть интересен шаблон проектирования Event Sourcing.

Event Sourcing гарантирует, что все изменения состояния приложения будут хранится как последовательность событий. Не просто мы можем запросить эти события, мы также может использовать журнал событий для восстановления прошлых состояний и как основа для автоматической настройки состояния, чтобы справиться с ретроактивным изменения.

Что касается хранения таких событий, это в действительности зависит от требований. Иногда достаточно просто сериализовать его в JSON.

Event Sourcing включен в большинство реализаций CQRS, поэтому вы можете найти дополнительную информацию практически в любом связанном с ней ресурсе.

Ответ 2

Вы можете использовать командный шаблон. Если вы добавите их в стек, у вас есть история.

Каждая команда имеет всю информацию, необходимую для выполнения своей задачи. Этот курс означает, что каждая команда является разборчивой, и ее довольно сложно сохранить и запросить для определенного вида пользователей (потому что пользователю нужно видеть информацию из команд, вызываемых другими (например, 15:00 Просмотренный элемент "Сильмариллион" снизил цену от 15 до 12,50 евро).

Вы можете представить команду в базе данных следующим образом:

Command
-------
id
name
timestamp
user

CommandParameters
-----------------
commandId
name
value

Теперь вы можете создать запрос, который показывает всю соответствующую команду для пользователя или определенного элемента, который пользователь имеет в своем списке просмотра (вы можете добавить таблицу, содержащую все команды, соответствующие для пользователя и элемента)

HistoryBuilder
--------------
viewName
commandName
filterField

Где для пользователя вы получаете всю команду, которая может быть выполнена конечными пользователями, а для элементов вы получаете все команды, связанные с такими элементами, как изменения запасов цен и т.д.

Теперь вы можете предоставить адаптеры для создания более удобных для пользователя сообщений из этих команд. Таким образом, вы можете использовать те же команды в других контекстах с другим адаптером.

Надеюсь, вам это поможет.

Ответ 3

Возможно, вы могли бы использовать подход, который Drupal и некоторые другие CMS'ы предпримут, то есть сохранить текущие и более старые версии одних и тех же данных в одной таблице. Более подробно описано здесь: Стратегии управления версиями CMS для контента

Не знаю, какое имя для этого шаблона, но я уверен, что он заработал сам.

Это имеет очевидное преимущество в скорости. С точки зрения отслеживания операций, введших каждое из этих изменений, вы можете использовать отдельную таблицу, возможно, с некоторыми ссылками на записи до и после изменения.