Таблицы аудита: каждое поле для таблицы или одной таблицы

в моем проекте все в порядке, кроме полей аудита. Просто вставка и обновление проверяются в нашей воображаемой вселенной.

Я предложил одну таблицу, похожую на следующие примеры:

но моя команда не думала так же, они помещали столбец в каждую таблицу для отслеживания обновления или вставки времени. А когда я спросил ... --21-->почему? они сказали мне, что так они следят за своей работой.

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

пример:

подход

Table Customer
+-------------+-------------+-----+--------------------------------+-------------+
| Name        | LastName    | ... | LastModification (Audit Field) | User        |
+-------------+-------------+-----+--------------------------------+-------------+
| varchar(30) | varchar(50) | ... | datetime                       | varchar(30) |
+-------------+-------------+-----+--------------------------------+-------------+

мой подходи!--3--> 

Table Customer
+-------------+-------------+-----+
| Name        | LastName    | ... |
+-------------+-------------+-----+
| varchar(30) | varchar(50) | ... |
+-------------+-------------+-----+

Table Audit
+-----------+------------+--------+------+-------------+
| TableName | TableField | Action | User | DateAndTime |
+-----------+------------+--------+------+-------------+

Итак, вопрос:

какой дизайн лучше, одна таблица, которая хранит историю транзакций или одно поле для каждой таблицы? (За и против)

16
audit database

1 ответов

что лучший дизайн, одна таблица которые держат историю сделки или одно поле для каждой таблицы? (За и против)

вместо того, чтобы сосредоточиться на 2 вариантах, вот ответ на 4 подхода, с которыми я работал на протяжении многих лет. Каждый со своими плюсами и минусами.

1. Всего три поля

просто добавьте три поля (последнее действие, time_stamp, update_user) в каждую таблицу и назовите это днем.

плюсы супер простой. Хорошо

минусы вы не можете сообщить о данных, которых у вас нет, поэтому эта структура не говорит вам почти ничего (кроме удалений)

2. Таблица клонов

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

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

минусы

3. Таблица Истории только

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

плюсы плюсы 2 но все это вставить. Меньше обслуживания, чем вариант 2.

минусы вы в конечном итоге потеряете прирост обслуживания, потому что вы будете в конечном итоге поддержания представлений или вы будете разбрызгивать get-the-current-record логику повсюду

4. Общая таблица аудита

эта таблица имеет четыре столбца (таблица*, Column_name, old_value, new_value ) и три поля аудита.

плюсы легкий для того чтобы настроить и поддержать.

минусы

  • его сложным, но он занимает много места, потому что ваш old_value и new_value поля должны быть nvarchar(max) или эквивалент, чтобы он мог принимать все, что есть в базовой таблице.

  • плохо работает при чтении и записи.

  • его боль, чтобы настроить строку за строкой отчета истории

  • если есть какой-либо рабочий процесс в отчетах аудита записей может стать нетривиальным. Например, вы получаете требование, чтобы пользователи хотели видеть изменения только после того, как состояние записей станет "утверждено". Это трудно даже в вариантах 2 и 3, но становится катастрофой в общем подходе к аудиту.

резюме

Я предпочитаю #2 подход к таблице клонов, поскольку он, похоже, работает лучше всего для меня. У меня были проблемы с #1 недостаточно и #4 может быть серьезным perf кошмар, который требует много работы, чтобы отменить.

27