0

行に関するメタデータの保存に関するベスト プラクティスは何ですか?

銀行間金融送金の例を見てみましょう。次のTransferようになります。

CREATE TABLE Transfers (
   TransferID int,
   FromTransit varchar(10),
   FromBranch varchar(10),
   FromAccount varchar(50),
   ToTransit varchar(10),
   ToBranch varchar(10),
   ToAccount varchar(50),
   Amount money,
   Status varchar(50));

しかし今ではもちろん、人々はメタデータを見たいと思うでしょう:

ALTER TABLE Transfers 
ADD
    CreatedDate datetime,
    LastModifiedDate datetime,
    CreatedByUsername varchar(50),
    CreatedByFullname varchar(200),
    CreatedByWorkstation varchar(50),

    VoidedDate datetime NULL,
    VoidedByUsername datetime NULL,
    VoidedByFullname datetime NULL,
    VoidApprovedBySupervisorUsername varchar(50) NULL,
    VoidApprovedBySupervisorFullname varchar(200) NULL,
    VoidApprovedBySupervisorWorkstation varchar(50) NULL,

    SentDate datetime NULL, 
    SentByUsername varchar(50) NULL,
    SentByFullname varchar(50) NULL,
    SentByWorkstation varchar(50) NULL,
    SendApprovedBySupervisorUsername varchar(50) NULL,
    SendApprovedBySupervisorFullname varchar(50) NULL,
    SendApprovedBySupervisorWorkstation varchar(50) NULL,
    SendConfirmationNumber varchar(50) NULL,
    SentToRemoteMachineName varchar(50) NULL,

    ReceivedDate datetime NULL, 
    ReceivedConfirmationNumber varchar(50) NULL,
    ReceivedToRemoteMachineName varchar(50) NULL,
    ReceivedByUsername varchar(50) NULL,
    ReceivedByFullname varchar(50) NULL,
    ReceivedByWorkstation varchar(50) NULL,
    ReceiveApprovedBySupervisorUsername varchar(50) NULL,
    ReceiveApprovedBySupervisorFullname varchar(50) NULL,
    ReceivedApprovedBySupervisorWorkstation varchar(50) NULL,

    ReceivedCheckedBySupervisorUsername varchar(50) NULL,
    ReceivedCheckedBySupervisorFullname varchar(50) NULL,
    ReceivedCheckedBySupervisorWorkstation varchar(50) NULL
)

これらはすべて明確に定義された値であり、転送に関連するハードコピーにすべて表示されます。

テーブルの変更の監査ログは既にありますが、次のようなものはキャッチされません。

UPDATE Transfers SET Status = 'TransferStatus_Received'
WHERE TransferID = 6744891

変更を加えた人のusername、fullname、およびmachine nameをキャッチします。しかし、転送の受け取りを「承認」する資格情報を入力するためにその人の肩越しにいたスーパーバイザーの名前を知ることはできません。

彼らが別の情報を追跡するように求めたとき、私の苛立ちが生じ、データテーブルにさらにメタデータ列を追加する必要がありました。

これはベストプラクティスですか？

4

2 に答える 2

2

更新を許可するため、これは財務データベースには適していません。更新を許可する場合、敵対的な当事者がそれらを更新する可能性があるため、ログ、監査、暗号化キー、または追加するものは何でも構いません。

代わりに、更新を禁止する必要があります。すべての変更は挿入である必要があります。すべてのテーブルにはインデックス付きのシーケンシャルFK列が必要であり、すべての結合がオンになっていMax(seq)ます。つまり、最新のデータに対してすべてのトランザクションを実行しますが、これらのテーブルにはすべてのトランザクションの永続的な記録があります。

編集：あなたが求めているのが元のテーブルに監査列を追加する必要があるかどうかである場合、それは監査列がスパースであるかnull許容であるかによって異なります。あなたのコメントから、彼らはそうだと思われます。

その場合、監査属性のnull許容グループごとに個別のテーブルを作成し、それらのテーブルに対して外部結合を実行して、元のデータベースの順次列と結合する必要があります。これは、データテーブルに影響を与えることなく、監査テーブルを自由に追加または削除できることを意味します。何かのようなもの：

SELECT t.transferID, t.money, u.Date, u.workstation, s.name, ...
FROM Transfers t
    LEFT OUTER JOIN Users u ON u.seq = t.seq
    LEFT OUTER JOIN Supervisors s ON s.seq = t.seq
WHERE t.seq = (SELECT Max(seq) FROM Transfers WHERE whatever)

Max(seq)トランザクションで再利用する必要がある場合に保存するビューまたはストアドプロシージャを作成できます。

于 2011-09-01T16:46:00.387 に答える
1

私はSQL Serverについてあまり知りませんが、Oracleのシナリオでそのようなことに直面したとき、完全な行（前後）を「アーカイブ/監査」テーブルに取り込んで追加するトリガー（挿入/更新/削除）を採用する傾向があります彼らがログに記録したい「メタデータ」は何でも...このようにして、アプリ中心のデータモデルはアプリケーション/SPなどに関して汚染されず、アプリ/ユーザーはその機密のログ/監査情報にアクセスできません...

于 2011-09-01T16:28:13.137 に答える