0

主キーの代理キーではなく自然キーを使用して SQL Server テーブルを設計しています。私が遭遇した問題は、過去にサロゲート キー テーブルで使用した監査テーブル形式ではうまく機能しないことです。通常、監査対象のテーブルと同じ列を持つ監査テーブルを作成します。監査対象の表に対するトリガーは、更新または削除前の行の状態と一致する新しい行を監査表に書き込みます。整合性を確保するために、テーブルの複合 PK としてサロゲート キーと変更日列の両方を使用します。サロゲート キーを使用しないと、複合キーを構成する列の 1 つが変更された場合に変更を追跡できません。

Log table example with Surrogate Key:

LogId (PK)
LogType
Data
ModifedDate
ModifedBy

LogAudit Table for Log table with Surrogate Key:

LogId (PK)
LogType
Data
ModifedDate (PK)
ModifedBy 


Log table example with Natural Key:

LogType (PK)
Data
ModifedDate (PK)
ModifedBy

LogAudit Table for Log table with Natural Key:
LogType 
Data
ModifedDate
ModifedBy

LogType または ModifiedDate が変更された場合、Audit テーブルの Natural Key Log テーブル レコードの変更をどのように追跡しますか?

4

2 に答える 2

2

ここで基本的な概念を誤解していると思います。

それがテーブル{LogType, ModifedDate}の自然キーであるLog場合 (ケース 2)、最初の例の代替キー (AK) (一意) であることも真です。

したがって、Log最初の例のテーブルは次のようになります。

LogId        (PK)
LogType      (AK1.1)
Data
ModifedDate  (AK1.2)
ModifedBy

したがって、与えられ{LogID}た{LogType, ModifedDate}は変更できず、その逆も同様です。

しかし、これはあなたが達成しようとしていることではありません。答えはおそらく、Logそもそもテーブルに「自然キー」がないことです。

コメントに従って編集

経験則として、行ベースの監査テーブルを作成するには:

  1. 元のテーブル構造 (列) をコピーします。

  2. ChangedAt(datetime)ChangedByと列をテーブルに追加します。

  3. ChangedAt元の PK に列を追加します。

  4. PK 列のコピーをテーブルに追加します。これは、PK の変更をキャプチャするためです。

  5. ON UPDATE CASCADE、ON DELETE NO ACTION で FK を追加します。これにより物理的な削除が防止されるため、論理的な削除を使用してください。

  6. 元のテーブルの AFTER INSERT、UPDATE トリガーから入力します。

例 1

      Table: {ID, SomeData}                               ; key: {ID} 
audit table: {ID, SomeData, ChangedAt, ChangedBy, ID_CPY} ; key: {ID, ChangedAt}

例 2

      Table: {UserID, UserOrderNo, SomeData}                       ; key: {UserID, UserOrderNo} 
audit table: {UserID, UserOrderNo, SomeData, ChangedAt, ChangedBy, UserID_CPY, UserOrderNo_CPY} ; key: {UserID, UserOrderNo, ChangedAt}

例 3 (説明による)

      Table: {LogType, ModifedDate, SomeData}                       ; key: {LogType, ModifedDate} 
audit table: {LogType, ModifedDate, SomeData, ChangedAt, ChangedBy, LogType_CPY, ModifedDate_CPY} ; key: {LogType, ModifedDate, ChangedAt}
于 2013-01-08T19:00:28.443 に答える
0

うーん、特にその自然キーは奇妙です。自然キーとサロゲート キーの両方のセットを使用することに制限はありません。PKにLogIDを使用し、LogType + ModifiedDateに一意のインデックスを作成する両方のテーブルを混合して、テーブルを結合するための単一のフィールドPKを持ち(これは良いことだと思います)、ビジネス/ナチュラルを持っています必要なもののキー（プライマリではなく一意）。

于 2013-01-07T19:54:22.313 に答える