Какова наилучшая архитектура для отслеживания изменений полей на объектах?
У нас есть веб-приложение, построенное на базе данных SQL. Некоторые из этих объектов нуждаются в отслеживании на уровне полей, аналогичном тому, как отслеживаются изменения полей в большинстве систем отслеживания проблем (например, статус, назначение, приоритет). Мы хотели бы показать, кем является изменение, каким было Предыдущее значение и какое новое значение.
на уровне чистого дизайна было бы проще всего отслеживать каждый изменение из любого объекта в общей таблице со столбцами для типа объекта, первичного ключа объекта, первичного ключа пользователя, внесшего изменение, имени Поля и старого и нового значений. В нашем случае они также могут иметь идентификатор комментария, если пользователь ввел комментарий при внесении изменений.
7 ответов
есть несколько вариантов, доступных для вас для этого. У вас могут быть таблицы аудита, которые в основном отражают базовые таблицы, но также включают дату/время изменения, тип изменения и пользователя. Они могут быть обновлены через триггер. Это решение, как правило, лучше для закулисного аудита (IMO), а не для решения специфического для приложения требования.
второй вариант, как вы описали. Вы можете иметь общую таблицу, которая содержит каждое отдельное изменение с помощью введите код, чтобы показать, какой атрибут был изменен. Мне лично не нравится это решение, поскольку оно предотвращает использование ограничений проверки на столбцах, а также может предотвратить ограничения внешнего ключа.
третий вариант(который был бы моим первоначальным выбором с приведенной информацией) будет иметь отдельную таблицу исторических изменений, которая обновляется через приложение и включает ПК для каждой таблицы, а также столбец (Ы), который вы будете отслеживать. Это немного отличается от первый вариант в том, что приложение будет отвечать за обновление таблицы по мере необходимости. Я предпочитаю это первому варианту в вашем случае, потому что у вас действительно есть бизнес-требование, которое вы пытаетесь решить, а не внутреннее техническое требование, такое как аудит. Помещая логику в приложение, у вас есть немного больше гибкости. Возможно, некоторые изменения вы не хотите отслеживать, потому что они обновления обслуживания и т. д.
в третьем случае вы можете либо "текущие" данные в базовой таблице или вы можете иметь каждый столбец, который хранится исторически только в исторической таблице. Затем вам нужно будет посмотреть последнюю строку, чтобы получить текущее состояние для объекта. Я предпочитаю это, потому что это позволяет избежать проблемы дублирования данных в вашей базе данных или необходимости просматривать несколько таблиц для одних и тех же данных.
Итак, вы могли бы:
Problem_Ticket (ticket_id, ticket_name) Problem_Ticket_History (ticket_id, change_datetime, описание, комментарий, имя пользователя)
кроме того, вы можете использовать:
Problem_Ticket (ticket_id, ticket_name) Problem_Ticket_Comments (ticket_id, change_datetime, комментарий, имя пользователя) Problem_Ticket_Statuses (ticket_id, change_datetime, status_id, username)
Я не уверен в конкретном подходе "отслеживания проблем", но я бы не сказал, что есть один окончательный способ сделать это. Есть несколько вариантов для этого, каждый из которых имеет свои преимущества и недостатки как показано здесь.
Я лично просто создайте одну таблицу, в которой есть несколько столбцов метаданных об изменении и столбец, в котором хранится xml сериализованной версии старого объекта или того, что вас волнует. Так, если хочешь. чтобы показать историю объекта, вы просто получите все старые версии и размочите их и все готово. Один стол, чтобы управлять ими всеми.
одно часто упускаемое решение можно использовать Изменить Захват Данных. Это может дать вам больше экономии места / производительности, если вы действительно обеспокоены.
удачи.
Это зависит от ваших точных требований, и это может быть не для вас, а для общего аудита в базе данных с триггерами (поэтому front-end и даже уровень интерфейса SP не имеют значения), мы используем AutoAudit, и она работает очень хорошо.
вот решение, которое я бы рекомендовал для достижения вашей цели.
дизайн вашего аудит модели как показано ниже.
---------------- 1 * ------------
| AuditEventType |----------| AuditEvent |
---------------- ------------
| 1 | 1
| |
----------------- -------------
| 0,1 | +
------------------- ----------------
| AuditEventComment | | AuditDataTable |
------------------- ----------------
| 1
|
|
| +
----------------- + 1 --------------
| AuditDataColumn |------------------| AuditDataRow |
----------------- --------------
.
AuditEventType
содержит список всех возможных типов событий в системе и общее описание для них.
.
AuditEvent
содержит информацию о конкретном даже том, что triggerd это действие.
.
AuditEventComment
содержит необязательный пользовательский комментарий пользователя о событии аудита. Комментарии могут быть действительно огромными, поэтому лучше хранить их в CLOB.
.
AuditDataTable
содержит список одной или нескольких таблиц, на которые повлиял соответствующий AuditEvent
.
AuditDataRow
содержит список одного или нескольких определение строк в соответствующем AuditDataTable, которые были затронуты соответствующим AuditEvent
.
AuditDataColumn
содержит список нулевых или более столбцов соответствующего AuditDataRow, значения которых были изменены с его предыдущими и текущими значениями.
.
AuditBuilder
реализовать AuditBuilder (шаблон Builder). Создайте экземпляр в начале события и сделайте его доступным в запросить контекст или передать его вместе с другими DTO. Каждый раз, когда вы вносите изменения в данные, вызывайте соответствующий вызов AuditBuilder, чтобы уведомить его об этом изменении. В конце вызовите build () на AuditBuilder для формирования структуры выше, а затем сохраните ее в базе данных.
убедитесь, что все ваши действия на событие в одной транзакции БД с сохранением данных аудита.
Я не понимаю фактических сценариев использования для проверенных данных... вам нужно просто следить за изменениями? Вам нужно будет "откатить" некоторые изменения? Как часто (и гибко) вы хотите, чтобы отчет журнала аудита/поиск был?
лично я бы расследовал что-то подобное:
Создать AuditTable. Это имеет идентификатор, номер версии, идентификатор пользователя и поле clob.
- при создании объекта #768795 добавьте строку в AuditTable, с значениями: Id=#768795 Версия:0 User: (Id пользователя, создавшего новый объект) clob: xml-представление всего объекта. (если пространство является проблемой, и доступ к этой таблице не часто, вы можете использовать blob и "zip" xml-представление на лету).
каждый раз, когда вы что-то меняете, создайте новую версию и сохраните весь объект "сериализованным" как XML Если вам нужно создать журнал аудита, у вас есть все, что вам нужно, и вы можете использовать простой " текст сравните " инструменты или библиотеки, чтобы увидеть, что изменилось во времени (немного похоже на Википедию).
Если вы хотите отслеживать только подмножество полей либо потому, что остальные неизменяемы, несущественны, либо вы отчаянно нуждаетесь в скорости/пространстве, просто сериализуйте подмножество, о котором вы заботитесь.
Я знаю, что этот вопрос очень старый, но другая возможность, которая встроена в sql ИЗМЕНЕНИЯ ТРЕКА:
вы можете найти более подробную информацию по этой ссылке: Введение в изменение системы сбора данных (CDC) в SQL Server 2008 http://www.simple-talk.com/sql/learn-sql-server/introduction-to-change-data-capture-(cdc)-in-sql-server-2008/