12

他の多くのシステムからのデータを格納するための中央リポジトリであるシステムを構築しています。他のシステムのデータが更新されたときに中央リポジトリを更新するには、同期プロセスが必要です。中央リポジトリが同期する必要があるシステムと必要な同期のタイプを識別するための sync_action テーブルがあります。変更される可能性が非常に低い一連の定義済みアクションがあります。スリム化されたシステムを以下に示します。

私が見ているように、これには2つの方法でアプローチできます。

オプション 1 ) Action3 つのアクションが利用可能なテーブルを用意します。sync_action外部キーを使用して必要なアクションを参照するテーブルを用意します。

表:システム

ID Description
 1 Slave System 1
 2 Slave System 2

表:アクション

ID  Description
 1  Insert
 2  Update
 3  Delete

表:同期アクション

ID  Action  System
 1     1       1
 2     2       1

オプション 2 ) 外部キーの代わりに、sync_action.action列にチェック制約を使用して、アクションのみInsert/Update/Deleteを挿入できるようにします。

表:同期アクション

ID  Action  System
1   Insert    1
2   Update    1

整合性制約、外部キーとチェック制約の間で決定するときに、どちらがより良いアプローチであるかを決定する要因を知りたいです。同様のスレッドがありましたが、十分に決定的なものではありませんでした。これは解釈次第かもしれませんが、どんな考えでも大歓迎です。

乾杯

4

2 に答える 2

8

コメンテーターは満場一致で同意しているようです：

一般FOREIGN KEYに、(多かれ少なかれ静的な) 参照テーブルに制約を設定することをお勧めします。理由:

  • 制約は簡単に「拡張可能」です。オプションを追加または削除するには、参照テーブルから行を追加または削除するだけです。制約を削除して再作成する必要はありません。さらに、他のテーブルの同様の列にも同じ制約がある場合。

  • 必要に応じてアプリケーションで読み取ることができる追加情報を添付できます (より多くの列)。

  • ORM は、これらの制約をより適切に処理できます (読む: 注意してください)。メタデータではなく、テーブルを読み取るだけです。

  • アクション コードを変更する場合は、カスケード効果が他の (場合によっては多くの) テーブルの変更を処理します。UPDATE クエリを記述する必要はありません。

  • 特定の DBMS には、FK 制約はありますが、まだCHECK制約が実装されていません (恥)。

@pst が述べたように (そして私はこのアプローチを非常に好みます)、サロゲート整数 ID の代わりに適切なコードを使用できます。したがって、テーブルは次のようになります。

表:システム

SystemID Description
 1        Slave System 1
 2        Slave System 2

表:アクション

ActionCode Description
 I          Insert
 U          Update
 D          Delete

表: SyncAction

ID  ActionCode  SystemID
 1     I          1
 2     U          1
于 2012-02-19T11:33:47.067 に答える
4

外部キー制約とチェック制約の違いを混同していると思います。

外部キー制約は参照整合性を強制するためにあり、チェック制約は有効なデータのみを含むように列を制約します。あなたの場合、これは小さな違いのように思えるかもしれませんが、少し抽象化すると、より明確になると思います.

users列を持つテーブルを考えるとuser_id, user_name, address_id, join_date, active, last_active_month; これが必ずしも最善の方法ではないことは認識していますが、私が言おうとしているポイントには役立つでしょう。

address_idこの場合、制約として持つのは明らかにばかげています。この列には、任意の数の値を含めることができます。ただし、activeブール値が必要であると仮定すると、y/n2 つの可能な値last_active_monthしか持てず、12 の可能な値しか持てません。どちらの場合でも、外部キーを持つことは完全にばかげています。特定の数の値しかなく、含めるデータの定義により、これらの値を変更することはできません。

あなたの場合、チェック制約に行くことができますが、の数が外部キーを決して変更しないことが絶対に確実でない限り、正しい方法です。actions

少し別の問題ですが、@pst が述べたように、代理キー モンスターに食べられたようです。これによりパフォーマンスが向上する可能性がありますが、想定しているサイズのテーブル (3 つの値insert / update / delete) またはさらに大きなサイズのテーブルでは、達成しようとしていることがわかりにくくなります。

見るのは簡単ではない

ID  Action  System
 1     1       1
 2     2       1

何が起こっているかを見てください、しかし：

ID  Action  System
 1  insert     1
 2  update     1

はるかに読みやすいです。列についても同じことを検討することをお勧めします。systemおそらくそうするでしょうが、可能な値の数はこれでわずかに跳ね上がります。あくまでも個人的な感想ですが…

于 2012-02-19T11:42:17.393 に答える