Лучший дизайн для таблицы базы данных журнала изменений / аудита? [закрыто]

Мне нужно создать таблицу базы данных для хранения различных журналов изменений / аудита (когда что-то было добавлено, удалено, изменено и т. Д.). Мне не нужно хранить особенно подробную информацию, поэтому я подумал что-то вроде:

• id (для события)
• пользователь, который вызвал это
• название события
• Описание события
• отметка времени события

Я что-то упустил? Очевидно, я могу продолжать улучшать дизайн, хотя я не планирую усложнять его (создание других таблиц для типов событий и тому подобное не может быть и речи, поскольку это усложнение для меня).

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

event ID
event date/time
event type
user ID
description

Идея была та же: все было просто.

Однако быстро стало очевидно, что этого минималистичного дизайна недостаточно. Типичный аудит сводился к следующим вопросам:

Who the heck created/updated/deleted a record 
with ID=X in the table Foo and when?

Итак, чтобы иметь возможность быстро отвечать на такие вопросы (с помощью SQL), мы получили два дополнительных столбца в таблице аудита.

object type (or table name)
object ID

Именно тогда дизайн нашего журнала аудита действительно стабилизировался (вот уже несколько лет).

Конечно, последнее «улучшение» будет работать только для таблиц с суррогатными ключами. Но знаете что? Все наши таблицы, которые стоит проверить, имеют такой ключ!

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

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

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

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

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

Подсказки:

• Включить значения до и после

• Включите 3-4 столбца для хранения первичного ключа (если это составной ключ)

• Хранить данные вне основной базы данных, как уже предложил Роберт

• Потратьте приличное количество времени на подготовку отчетов - особенно тех, которые могут понадобиться для восстановления

• Планирование хранения имени хоста / приложения - это может быть очень полезно для отслеживания подозрительных действий.

Здесь и на подобные вопросы много интересных ответов. Единственное, что я могу добавить из личного опыта:

1. Поместите свою таблицу аудита в другую базу данных. В идеале вы хотите отделиться от исходных данных. Если вам нужно восстановить базу данных, вы действительно не хотите восстанавливать журнал аудита.

2. Денормализуйте насколько это возможно. Вы хотите, чтобы таблица имела как можно меньше зависимостей от исходных данных. Таблица аудита должна быть простой и молниеносной для извлечения данных. Никаких причудливых объединений или поисков в других таблицах для доступа к данным.

Что у нас в таблице: -

Primary Key
Event type (e.g. "UPDATED", "APPROVED")
Description ("Frisbar was added to blong")
User Id
User Id of second authoriser
Amount
Date/time
Generic Id
Table Name

Общий идентификатор указывает на строку в таблице, которая была обновлена, а имя таблицы - это имя этой таблицы в виде строки. Не очень хороший дизайн БД, но очень удобный. Во всех наших таблицах есть один столбец суррогатного ключа, так что это хорошо работает.

В целом кастомный аудит (создание различных таблиц) - плохой вариант. Триггеры базы данных / таблицы можно отключить, чтобы пропустить некоторые действия журнала. Настраиваемые таблицы аудита могут быть изменены. Могут иметь место исключения, которые приведут к остановке приложения. Не упоминать о трудностях разработки надежного решения. Пока я вижу в этом обсуждении очень простые случаи. Вам необходимо полное отделение от текущей базы данных и от любых привилегированных пользователей (администраторов баз данных, разработчиков). Каждая распространенная СУБД предоставляет средства аудита, которые даже администратор баз данных не может отключить, нарушая конфиденциальность. Следовательно, возможность аудита, предоставляемая поставщиком РСУБД, должна быть первым вариантом. Другим вариантом может быть стороннее средство чтения журнала транзакций или пользовательское средство чтения журнала, которое отправляет разложенную информацию в систему обмена сообщениями, которая в конечном итоге оказывается в некоторых формах хранилища данных аудита или обработчика событий в реальном времени. В итоге: Архитектор решений / «Практикующий архитектор данных» должен участвовать в создании такой системы на основе требований. Обычно это слишком серьезные вещи, чтобы просто передать их разработчикам для решения.

Есть много способов сделать это. Мой любимый способ:

1. Добавьте mod_userполе в исходную таблицу (то, которое вы хотите зарегистрировать).

2. Создание таблицы журнала , который содержит поле , которые вы хотите , чтобы войти, плюс log_datetimeи seq_numполе. seq_numэто первичный ключ.

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

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

По принципу разделения:

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

2. Не используйте триггеры для аудита всей базы данных, потому что вам придется поддерживать множество разных баз данных. Вам нужно будет написать один для DB2, SQLServer, Mysql и т. Д.