Projektowanie baz danych do rejestrowania audytów

Jeśli używasz SQL Server 2008, prawdopodobnie powinieneś rozważyć zmianę przechwytywania danych. Jest to nowość na rok 2008 i może zaoszczędzić znaczną ilość pracy.

Nie znam żadnego odniesienia, ale jestem pewien, że ktoś coś napisał.

Jeśli jednak celem jest po prostu posiadanie zapisu tego, co się stało-najbardziej typowego użycia dziennika audytu-to dlaczego po prostu nie zachować wszystkiego:

timestamp
username
ip_address
procedureName (if called from a stored procedure)
database
table
field
accesstype (insert, delete, modify)
oldvalue
newvalue

Prawdopodobnie jest to utrzymywane przez wyzwalacz.

Myślę, że nie ma to jak drzewo decyzyjne. Ponieważ niektóre plusy i minusy (lub wymagania) nie są naprawdę policzalne. Jak mierzyć na przykład dojrzałość?

Więc po prostu dostosuj swoje wymagania biznesowe do rejestrowania audytu. Spróbuj przewidzieć, jak te wymagania mogą się zmienić w przyszłości i wygenerować swoje wymagania techniczne. Teraz możesz porównać go do zalet i wad i wybrać właściwą / najlepszą opcję.

I bądź pewny, nie ma znaczenia, jak ty zdecyduj, zawsze będzie ktoś, kto myśli, że podjąłeś złą decyzję. Jednak odrobiłeś swoją pracę domową i uzasadniasz swoją decyzję.

Stworzymy małą przykładową bazę danych dla aplikacji blogowej. Wymagane są dwie tabele:

blog: przechowuje unikalny identyfikator posta, tytuł, zawartość i usuniętą flagę. audit: przechowuje podstawowy zestaw historycznych zmian z identyfikatorem rekordu, identyfikatorem posta na blogu, typem zmiany (Nowa, Edycja lub usunięcie) oraz datą / godziną tej zmiany. Poniższy SQL tworzy blog i indeksuje usuniętą kolumnę:

CREATE TABLE `blog` (
    `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
    `title` text,
    `content` text,
    `deleted` tinyint(1) unsigned NOT NULL DEFAULT '0',
    PRIMARY KEY (`id`),
    KEY `ix_deleted` (`deleted`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='Blog posts';

Poniższy SQL tworzy tabelę audit. Wszystkie kolumny są indeksowane i klucz obcy jest definiowany do audytu.blog_id blog.id. dlatego, gdy fizycznie usuwamy wpis na blogu, usuwa się również pełną historię audytu.

CREATE TABLE `audit` (
    `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
    `blog_id` mediumint(8) unsigned NOT NULL,
    `changetype` enum('NEW','EDIT','DELETE') NOT NULL,
    `changetime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (`id`),
    KEY `ix_blog_id` (`blog_id`),
    KEY `ix_changetype` (`changetype`),
    KEY `ix_changetime` (`changetime`),
    CONSTRAINT `FK_audit_blog_id` FOREIGN KEY (`blog_id`) REFERENCES `blog` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;