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

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

12 голосов
/ 23 августа 2011

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

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

  • 16: 00 Вы купили "Властелин колец" в транзакции 2468,
  • 15: 30 Вы добавили "Хоббит" в свой список наблюдения,
  • 15: 00 «Сильмариллион» просматриваемого товара снизил цену с 15 до 12,50 евро,
  • 14: 30 Вы изменили свое имя с «Томаш» на «Том».

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

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

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

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

Ответы [ 3 ]

6 голосов
/ 23 августа 2011

Возможно, вас заинтересует шаблон проектирования под названием Event Sourcing .

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

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

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

2 голосов
/ 23 августа 2011

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

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

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

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

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

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

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

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

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

Надеюсь, это продвинет вас дальше.

0 голосов
/ 23 августа 2011

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

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

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

...