Лучший дизайн для таблицы базы данных изменений/аудита?

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Подсказки:

Включить до/после значения
Включите 3-4 столбца для хранения первичного ключа (если это составной ключ)
Храните данные вне основной базы данных, как уже предложено Робертом
Потратьте приличное количество времени на подготовку отчетов - особенно тех, которые вам могут понадобиться для восстановления
Планирование хранения имени хоста/приложения - это может оказаться очень полезным для отслеживания подозрительных действий

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Добавьте поле mod_user в исходную таблицу (ту, которую вы хотите зарегистрировать).
Создайте таблицу журнала, содержащую поля, которые вы хотите зарегистрировать, а также log_datetime и seq_num. seq_num является первичным ключом.
Создайте триггер на исходной таблице, который вставляет текущую запись в таблицу журнала при каждом изменении любого отслеживаемого поля.

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

Ответ 6

Что мы имеем в нашей таблице: -

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

Поздно к вечеринке, но я настоятельно рекомендую проект AutoAudit.
Это 100% бесплатно и с открытым исходным кодом. Он был автором SQL MVPs Paul Nielsen и John Sigouin. Он очень стабилен и в настоящее время находится на версии 3.30.

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