監査ログのデータベース設計 [closed] 質問する

Question

いくつかの wiki プラットフォームで使用されている方法の 1 つは、識別データと監査対象のコンテンツを分離することです。これにより複雑さが増しますが、古いレコードがどのようなものであったかをユーザーに知らせるために編集されたフィールドのリストをマッシュアップする必要がなくなるため、完全なレコードの監査証跡が得られます。

例えば、次のようなテーブルがあったとします機会販売取引を追跡するには、実際には 2 つの別々のテーブルを作成します。

機会
機会_コンテンツ（またはそのようなもの）

の機会テーブルには、レコードを一意に識別するための情報と、外部キー関係を参照するための主キーが格納されます。機会_コンテンツテーブルには、ユーザーが変更でき、監査証跡を残したいすべてのフィールドが含まれます。コンテンツテーブルには独自の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

Revision が ID タイプである場合、コンテンツテーブルの PK を PageID と Revision からの複数列キーにすると思います。Revision 列を FK として使用します。次に、次のように JOIN して統合レコードを取得します。

SELECT * FROM Page
JOIN PageContent ON CurrentRevision = Revision AND ID = PageID

いくつか間違いがあるかもしれません...これは私の頭に浮かんだものです。ただし、別のパターンのアイデアは得られるはずです。

Answer 1