Проектирование базы данных для ведения журнала аудита
4 ответа
Один из методов, который используется несколькими вики-платформами, заключается в разделении идентификационных данных и содержимого, которое вы проверяете. Это добавляет сложности, но в конечном итоге вы получаете аудиторский след из полных записей, а не просто список полей, которые были отредактированы, а затем вы должны расплющить, чтобы дать пользователю представление о том, как выглядела старая запись.
Так, например, если бы у вас была таблица под названием Возможности для отслеживания сделок купли-продажи, вы бы создали две отдельные таблицы:
Возможности
Возможности_контент (или что-то в этом роде)
Таблица Возможности содержала бы информацию, которую вы бы использовали для уникальной идентификации записи, и содержала бы первичный ключ, на который вы бы ссылались для ваших отношений с иностранными ключами. В таблице Opportunities_Content будут сохранены все поля, которые могут быть изменены вашими пользователями, и для которых вы хотели бы вести журнал аудита. Каждая запись в таблице Content будет содержать свой собственный PK и данные с измененными датами. Таблица Возможности будет включать ссылку на текущую версию, а также информацию о том, когда изначально была создана основная запись и кем.
Вот простой пример:
CREATE TABLE dbo.Page(
ID int PRIMARY KEY,
Name nvarchar(200) NOT NULL,
CreatedByName nvarchar(100) NOT NULL,
CurrentRevision int NOT NULL,
CreatedDateTime datetime NOT NULL
И содержимое:
CREATE TABLE dbo.PageContent(
PageID int NOT NULL,
Revision int NOT NULL,
Title nvarchar(200) NOT NULL,
User nvarchar(100) NOT NULL,
LastModified datetime NOT NULL,
Comment nvarchar(300) NULL,
Content nvarchar(max) NOT NULL,
Description nvarchar(200) NULL
Я, вероятно, сделаю PK таблицы содержимого многоколоночным ключом из PageID и Ревизии при условии, что Ревизия была идентификационным типом. Вы бы использовали колонку Revision в качестве FK. Затем вы извлекаете консолидированную запись JOINing следующим образом:
SELECT * FROM Page
JOIN PageContent ON CurrentRevision = Revision AND ID = PageID
Там могут быть некоторые ошибки...это у меня в голове. Но это должно дать вам представление об альтернативном шаблоне.
] Я не знаю ни одной ссылки, но я уверен, что кто-то что-то написал.[
] [] Однако, если цель заключается в том, чтобы просто иметь запись того, что произошло - наиболее типичное использование журнала аудита - почему бы просто не сохранить все:[
] [timestamp
username
ip_address
procedureName (if called from a stored procedure)
database
table
field
accesstype (insert, delete, modify)
oldvalue
newvalue
]Предположительно, это поддерживается триггером.[
].Если вы используете SQL Server 2008, вам, вероятно, следует подумать об изменении сбора данных. Это новинка для 2008 года и может сэкономить вам значительный объем работы.
Я думаю, нет ничего лучше дерева решений. Так как некоторые "за" и "против" (или требования) на самом деле не считаются. Как вы измеряете, например, зрелость?
Так что просто выстраивайте свои бизнес-требования к аудиторским лесозаписям. Попробуйте предсказать, как эти требования могут измениться в будущем, и сгенерируйте свои технические требования. Теперь вы можете сравнить его с плюсами и минусами и выбрать правильный/лучший вариант.
И будьте уверены, неважно, как вы решите, всегда будет кто-то, кто думает, что вы приняли неверное решение. Однако, вы сделали домашнее задание и обосновываете свое решение.