5

source_id値が別のテーブルの主キーである必要がある1つの列を持つテーブルがありますが、どのテーブルであるかはレコードごとに異なります。すべてのレコードsource_tableには、ソース レコードのテーブルを指定する の値とsource_id、ソース テーブルの行を指定する の値が必要です。

DB の外部キー制約と検証を利用するためにこれを達成する方法はありますか? または、検証ロジックをアプリケーション層に移動する必要がありますか? あるいは、この問題を回避できる別の設計はありますか?

4

2 に答える 2

5

外部キー制約は、1 つのターゲット テーブルのみを参照できます。他のフィールドに基づいて別のターゲット テーブルを参照する「条件付き」外部キーは、SQL では使用できません。以下のコメントで@OMG Poniesが指摘したように、複数のテーブルを参照して、同じ列に複数の外部キーを持つことができますが、それは、その列の値が参照されるすべてのテーブルに存在する必要があることを意味します。これはあなたが求めているものではないと思います。

考えられるいくつかの解決策については、この質問に対する@Bill Karwin の回答を確認することをお勧めします。

私は一般的に「優れた」アプローチが好きです。別の例については、この投稿をチェックすることもできます。

于 2010-08-22T03:41:15.670 に答える
1

以前の回答は、質問の最初の部分にうまく答えていると思います。ただし、ダニエルが推奨するリンクは、参照される「ソース」テーブルの数がかなり少ない場合にのみ解決策を提供します。また、「ソース」テーブルの数を増やすことにした場合、ソリューションは簡単には拡張できません。

より良い戦略を推奨するには、タスクが何であるか、および「ソース」テーブルにそれらを組み合わせることができる共通点があるかどうかについて、もう少し詳しく説明するとよいでしょう。

現在の構造では（質問から推測できる限り）、関係を逆にします。

  1. source_id 列と source_table 列を持つすべての利用可能なソースのリポジトリとして機能するテーブル (AllSources と呼びましょう) を作成します。どちらも主キーに含まれています。
  2. AllSources テーブルを参照する各「ソース」テーブルから外部キーを作成して、既に登録されているソースのみを保持できるようにします。
  3. 次に、AllSources テーブルを参照する外部キーを使用して、質問で言及したテーブルを作成します (別の「ソース」テーブルではありません)。

欠点: AllSources と「ソース」テーブルを一緒に管理して、AllSources でレコードを作成する場合、適切な「ソース」テーブルにも対応するレコードを作成する必要がありますが、実際にはそれほど難しくありません。

于 2010-08-22T04:21:09.577 に答える