Какова наилучшая архитектура для отслеживания изменений поля на объектах?

Для этого у вас есть несколько вариантов. У вас могут быть таблицы аудита, которые в основном отражают базовые таблицы, но также включают дату/время изменения, тип изменения и пользователя. Их можно обновить с помощью триггера. Это решение, как правило, лучше подходит для аудита за кулисами (IMO), а не для решения конкретных требований приложения.

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

Третий вариант (который был бы моим первоначальным выбором с предоставленной информацией) состоял бы в том, чтобы иметь отдельную таблицу исторических изменений, которая обновляется через приложение и включает PK для каждой таблицы, а также столбцы, которые вы будете отслеживать . Он немного отличается от первого варианта тем, что приложение будет отвечать за обновление таблицы по мере необходимости. Я предпочитаю это первому варианту в вашем случае, потому что у вас действительно есть бизнес-требование, которое вы пытаетесь решить, а не внутреннее техническое требование, такое как аудит. Поместив логику в приложение, вы получаете немного больше гибкости. Возможно, некоторые изменения вы не хотите отслеживать, потому что они являются обновлениями обслуживания и т. д.

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

Итак, у вас может быть:

Проблема_Заявки (идентификатор_заявки, имя_заявки) Проблема_Заявки_История (идентификатор_заявки, дата_время изменения, описание, комментарий, имя пользователя)

В качестве альтернативы вы можете использовать:

Проблема_Заявки (идентификатор_заявки, имя_заявки) Проблема_Заявки_Комментарии (идентификатор_заявки, дата_время изменения, комментарий, имя пользователя) Проблема_Заявки_Статусы (идентификатор_заявки, дата-время_изменения, идентификатор_состояния, имя пользователя)

Я не уверен в конкретном подходе к «отслеживанию проблем», но я бы не сказал, что есть один окончательный способ сделать это. Существует несколько способов сделать это, каждый из которых имеет свои преимущества и недостатки, как показано здесь< /а>.

Одним из часто упускаемых из виду решений может быть использование Change Data Capture. . Это может дать вам больше экономии места/производительности, если вы действительно обеспокоены.

Это зависит от ваших конкретных требований, и это может быть не для вас, но для общего аудита в базе данных с помощью триггеров (поэтому внешний интерфейс и даже уровень интерфейса SP не имеют значения) мы используем AutoAudit, и он работает очень хорошо.

Вот решение, которое я бы порекомендовал для достижения вашей цели.

Разработайте свою модель аудита, как показано ниже.

  ----------------  1      *  ------------                       
 | AuditEventType |----------| AuditEvent |                      
  ----------------            ------------                       
                                | 1    | 1                       
                                |      |                         
               -----------------        -------------            
              | 0,1                                  | +         
    -------------------                       ----------------   
   | AuditEventComment |                     | AuditDataTable |  
    -------------------                       ----------------   
                                                     | 1         
                                                     |           
                                                     |           
                                                     | +         
          -----------------  +             1  --------------     
         | AuditDataColumn |------------------| AuditDataRow |   
          -----------------                   --------------     

.

Тип события аудита

Содержит список всех возможных типов событий в системе и их общее описание.

.

Событие аудита

Содержит информацию о конкретных событиях, вызвавших это действие.

.

Комментарий к событию аудита

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

.

Таблица данных аудита

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

.

Строка данных аудита

Содержит список одной или нескольких идентифицирующих строк в соответствующей таблице AuditDataTable, на которые повлияло соответствующее событие AuditEvent.

.

Колонка данных аудита

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

.

Конструктор аудита

Реализуйте AuditBuilder (шаблон Builder). Создайте экземпляр в начале события и сделайте его доступным в контексте запроса или передайте его вместе с другими DTO. Каждый раз, когда в любом месте вашего кода вы вносите изменения в свои данные, вызывайте соответствующий вызов AuditBuilder, чтобы уведомить его об изменении. В конце вызовите build() в AuditBuilder, чтобы сформировать вышеуказанную структуру, а затем сохраните ее в базе данных.

Убедитесь, что все ваши действия для события находятся в одной транзакции БД вместе с сохранением данных аудита.

Я не понимаю реальных сценариев использования проверенных данных, однако... вам нужно просто отслеживать изменения? Нужно ли будет «откатывать» некоторые изменения? Насколько частым (и гибким) должен быть отчет/поиск в журнале аудита?

Лично я бы исследовал что-то вроде этого:

Создайте таблицу аудита. У него есть идентификатор, номер версии, идентификатор пользователя и поле clob.

• Когда объект #768795 будет создан, добавьте строку в AuditTable со значениями: Id=#768795 Версия:0 Пользователь: (идентификатор пользователя, создавшего новый объект) clob: xml-представление всего объекта. (если пространство является проблемой и доступ к этой таблице нечастый, вы можете использовать большой двоичный объект и «архивировать» представление xml на лету).

Каждый раз, когда вы что-то меняете, создаете новую версию и сохраняете весь объект «сериализованным» в виде XML. что изменилось со временем (немного похоже на Википедию).

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

Я знаю, что этот вопрос очень старый, но еще одна возможность, встроенная в sql, - это ИЗМЕНЕНИЯ ОТСЛЕЖИВАНИЯ:

вы можете найти дополнительную информацию по этой ссылке: Введение в сбор данных об изменениях (CDC) в SQL Server 2008 http://www.simple-talk.com/sql/learn-sql-server/introduction-to-захват-изменения-данных-(cdc)-in-sql-server-2008/

Я думаю, что Observer — идеальный шаблон в этом сценарии.