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

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

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

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

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

Пример:

Их подход

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 - серьезным кошмаром, который требует много работы для отмены.