Таблицы аудита: каждое поле для таблицы или одной таблицы - PullRequest
Новая
       4

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

18 голосов
/ 02 ноября 2011

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

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

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

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

Пример: * * тысяча двадцать-пять

Их подход 

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

Мой подход 

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

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

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

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

1 Ответ

30 голосов
/ 02 ноября 2011

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

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

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

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

Плюсы Супер просто. Хорошо выполняет

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

2. Стол клонов

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

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

Минусы

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

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

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

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

4. Общий аудиторский стол

В этой таблице есть четыре столбца (Таблица *, Имя столбца, старое_значение, новое_значение) и три поля аудита.

Плюсы Простота установки и обслуживания.

Минусы

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

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

  • Трудно настроить ряд по отчету истории строк

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

Резюме

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

...