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

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

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

лучший дизайн для таблицы базы данных изменений/аудита?
Предложения по внедрению таблиц аудита в SQL Server? Просто имя таблицы, столбец таблицы, пользователь, действие и дата.

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

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

Пример:

Их подход

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 |
+-----------+------------+--------+------+-------------+

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

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

Ответ 1

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

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

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

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

Профи Супер легкий. Хорошо работает

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

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

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

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

Против

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

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

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

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

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

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

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

Преимущества. Простота настройки и обслуживания.

Против

Неинтуитивно, но занимает много места, потому что ваши поля old_value и new_value должны быть nvarchar(max) или эквивалентными, чтобы он мог принимать все, что содержится в вашей базовой таблице.
Выполняет плохое чтение и запись.
Его боль, чтобы настроить отчет истории строк за строкой
Если какой-либо рабочий процесс в отчетах аудита отчетов может стать нетривиальным. Например, вы получаете требование, чтобы пользователи только хотели видеть изменения, которые происходят после того, как статус в отчетах становится "утвержденным". Это сложно даже в вариантах 2 и 3, но становится катастрофой в общем подходе к аудиту.

Резюме

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