sql - 主テーブルに存在しないデフォルト値を持つ外部キー

Question

これが私の状況です。列の値を NULL、0、または別のテーブルの値にすることができるテーブルがあります。もう一方のテーブルには、どの行にも 0 の値がありません。

私の最良の選択肢は何ですか？

1) FK を追加しないでください。

2) 外部テーブルに 0 レコードを追加します。

3) 他の何か。

0 の値を null に変更できません。0 は有効な値を表します。

助けてくれてありがとう。

Answer 1

私は個人的にスキーマを調べます-この列は外部キーであるかそうでないかのどちらかです-列を2つの異なる目的に使用しようとしているように聞こえます（「0は有効な値を表します」）。スキーマを変更して本物のFK列を追加できない場合は、ソリューション1を次善の策として使用してください（IMO）

Answer 2

付きのチェック制約EXISTS(SELECT 1 FROM OtherTable WHERE fkv=v) OR v=0はオプションです。ただし、パフォーマンス上の理由から、実際の外部キーが常に優先されます。（SQL Serverは、クエリの最適化中に宣言された外部キーの関係を利用でき、利用する予定です。多くの場合、クエリがはるかに高速になります。）

また、RaphaëlAlthausが述べたように、チェック制約は、子テーブルのレコードを挿入または更新するときにのみチェックされます。親レコードの削除は、既存の子が存在する場合でも、影響はありません。（ただし、そのためにトリガーを追加できます）

全体として、「0」レコードを追加し、実際の外部キーを宣言することが最善の策です。

Answer 3

0 が有効な値である場合、「外部テーブル」のレコードとして個人的に 0 を追加します。

または 3) FOREIGN KEY の代わりに CHECK CONSTRAINT を使用します。

しかし、答えは「ベストプラクティスの一般的な答え」として1）または2）または3）にすることはできません：それはあなたのニーズに依存します（あなたのテーブルに関連する何かが外部テーブルで削除されたときに何が起こるべきかは考慮すべき最も重要なこと）。

チェック制約の弱点 :

http://msdn.microsoft.com/en-us/library/ms188258(v=sql.105).aspx

CHECK 制約は、DELETE ステートメント中に検証されません。したがって、特定のタイプのチェック制約を持つテーブルで DELETE ステートメントを実行すると、予期しない結果が生じる場合があります。たとえば、テーブル CheckTbl で実行される次のステートメントについて考えてみます。