То, какова лучшая архитектура для отслеживания поля, изменяется на объектах?
Я глубоко убежден, что Graphviz не следует использовать таким образом, но вы можете использовать HTML-метки для достижения желаемого:
digraph {
Foo -> Bar -> Test;
Foo -> Baz -> Test;
{ rank = sink;
Legend [shape=none, margin=0, label=<
Legend
Foo
Foo
Bar
Baz
Test
Test
>];
}
}
Вот что это выглядит например:
[/g1]
Позиционирование Легенды должно выполняться, как и любой другой узел (я использовал ранг = раковина, чтобы получить его снизу) - вы можете играть со своим атрибутом margin для точной настройки положения.
Изменить:
Без использования меток, на которые может идти направление - я не уверен полностью ли исключить ranksep.
digraph {
mindist=0;
ranksep=0;
nodesep=0;
node[shape=box,margin="0,0",width=1, height=0.5];
edge [style=invis];
Legend[width=2];
Legend -> Foo;
Legend -> FooValue;
Foo -> Bar;
FooValue -> BarValue
Bar -> Baz;
BarValue -> BazValue;
edge [constraint=false];
Foo -> FooValue;
Bar -> BarValue
Baz -> BazValue;
}
Результат:
[/g2]
7 ответов
Для этого есть несколько вариантов. Вы можете иметь таблицы аудита, которые в основном отражают базовые таблицы, но также включают дату / время изменения, тип изменения и пользователя. Они могут быть обновлены через триггер. Это решение, как правило, лучше для внутреннего аудита (IMO), а не для решения специфичных для приложения требований.
Второй вариант, как вы описали. Вы можете иметь общую таблицу, которая содержит каждое отдельное изменение с кодом типа, чтобы показать, какой атрибут был изменен. Мне лично не нравится это решение, так как оно предотвращает использование проверочных ограничений для столбцов, а также может предотвращать ограничения внешнего ключа.
Третий вариант (который будет моим первоначальным выбором с предоставленной информацией) будет состоять в том, чтобы иметь отдельную таблицу исторических изменений, которая обновляется через приложение и включает в себя PK для каждой таблицы, а также столбцы, которые вы будет отслеживать. Он немного отличается от первого варианта тем, что приложение будет отвечать за обновление таблицы по мере необходимости. Я предпочитаю это первому варианту в вашем случае, потому что у вас действительно есть бизнес-требование, которое вы пытаетесь решить, а не внутреннее техническое требование, такое как аудит. Поместив логику в приложение, вы получаете немного больше гибкости. Может быть, некоторые изменения вы не хотите отслеживать, потому что они являются обновлениями обслуживания и т. Д.
С третьим вариантом вы можете либо иметь «текущие» данные в базовой таблице, либо вы можете иметь каждый столбец, который исторически хранится только в исторической таблице. Затем вам нужно будет просмотреть последнюю строку, чтобы получить текущее состояние объекта. Я предпочитаю это, потому что это позволяет избежать проблемы дублирования данных в вашей базе данных или необходимости просматривать несколько таблиц для получения одних и тех же данных.
Таким образом, вы можете иметь:
Problem_Ticket (ticket_id, ticket_name) Problem_Ticket_History (ticket_id, change_datetime, description, comment, username)
В качестве альтернативы вы можете использовать:
Problem_Ticket (ticket_id, ticket_name) Problem_Ticket_Comments (ticket_id, change_datetime, комментарий, имя пользователя) Problem_Ticket_Statuses (ticket_id, change_datetime, status_id, имя пользователя)
Это зависит от ваших точных требований, и это может быть не для вас, но для общего аудита в базе данных с триггерами (поэтому внешний интерфейс и даже уровень интерфейса SP не имеют значения), мы используем AutoAudit , и это работает очень хорошо.
Я не понимаю реальных сценариев использования для проверенных данных, хотя ... вам нужно просто отслеживать изменения? Нужно ли будет «откатить» некоторые изменения? Насколько часто (и гибко) вы хотите, чтобы отчет / просмотр журнала аудита были?
Лично я бы исследовал нечто подобное:
Создать AuditTable. Он имеет идентификатор, номер версии, идентификатор пользователя и поле Clob.
- Когда объект № 768795 создан, добавьте строку в AuditTable со значениями: Id = # 768795 Версия: 0 Пользователь: (идентификатор пользователя, создавшего новый объект) clob: представление в формате xml всего объект. (если пробел является проблемой, и доступ к этой таблице не част, вы можете использовать BLOB-объект и «сжать» представление xml на лету).
Каждый раз, когда вы что-то меняете, создаете новую версию и сохраняете весь объект, «сериализованный» в виде XML. Если вам нужно создать журнал аудита, у вас есть все, что вам нужно, и вы можете использовать простое сравнение текста «инструменты или библиотеки, чтобы увидеть, что со временем изменилось (немного как в Википедии).
Если вы хотите отслеживать только подмножество полей либо потому, что остальное является неизменным, незначительным, либо вы отчаянно нуждаетесь в скорости / пространстве, просто сериализуйте подмножество, которое вас волнует.
Я знаю, что этот вопрос очень старый, но еще одна возможность, встроенная в sql, - это ИЗМЕНЕНИЯ ТРАКА:
вы можете найти больше информации по этой ссылке: Введение в сбор данных изменений (CDC) в SQL Server 2008 http://www.simple-talk.com/sql/learn-sql-server/introduction-to-change-data-capture- (CDC) -в-SQL-Server-2008 /
Я думаю, что Observer является идеальной моделью в этом сценарии.
Вот решение, которое я бы рекомендовал для достижения вашей цели.
Разработайте свою модель аудита, как показано ниже.
---------------- 1 * ------------
| AuditEventType |----------| AuditEvent |
---------------- ------------
| 1 | 1
| |
----------------- -------------
| 0,1 | +
------------------- ----------------
| AuditEventComment | | AuditDataTable |
------------------- ----------------
| 1
|
|
| +
----------------- + 1 --------------
| AuditDataColumn |------------------| AuditDataRow |
----------------- --------------
.
AuditEventType
Содержит список всех возможных типов событий в системе и общее описание для них.
.
AuditEvent
Содержит информацию о конкретном событии, которое вызвало данное действие.
.
AuditEventComment
Содержит необязательный пользовательский комментарий о событии аудита. Комментарии могут быть очень большими, поэтому лучше хранить их в CLOB.
.
AuditDataTable
Содержит список одной или более таблиц, которые были затронуты соответствующим событием аудита
.
AuditDataRow
Содержит список одной или более идентифицирующих строк в соответствующей AuditDataTable, которые были затронуты соответствующим AuditEvent
.
AuditDataColumn
Содержит список из нуля или более столбцов соответствующего AuditDataRow, значения которых были изменены на предыдущие и текущие.
.
AuditBuilder
Реализуйте AuditBuilder (паттерн Builder). Инстанцируйте его в начале события и сделайте его доступным в контексте запроса или передайте его вместе с другими DTO. Каждый раз, когда в любом месте вашего кода вы вносите изменения в данные, вызывайте соответствующий вызов AuditBuilder, чтобы уведомить его об изменении. В конце вызовите build() на AuditBuilder, чтобы сформировать вышеуказанную структуру, а затем персистируйте ее в базу данных.
Убедитесь, что все ваши действия для события находятся в одной транзакции БД вместе с сохранением данных аудита.
Я не уверен насчет конкретного подхода к «отслеживанию проблем», но я бы не сказал, что есть единственный способ сделать это. Для этого существует ряд вариантов, каждый из которых имеет свои преимущества и недостатки , как показано здесь .
Я лично просто создал бы одну таблицу, в которой есть несколько столбцов метаданных об изменении и столбец, в котором хранится xml сериализованной версии старого объекта или того, что вам нужно. Таким образом, если вы хотите показать историю объекта, вы просто получите все старые версии, обновите их, и все готово. Одна таблица, чтобы управлять ими всеми.
Одним из часто игнорируемых решений было бы использование системы отслеживания измененных данных . Это может дать вам больше экономии места / производительности, если вы действительно обеспокоены.
Удачи.