SQL Serverのテーブルに複数のNULL可能FKを設定するのは悪い習慣と見なされますか

13

SQL Serverのデータベース構造には、注文に関するさまざまな情報を必要とする3種類の製品があります。だから、私は1つ作成しCustomers、テーブルと三つの異なる受注テーブルを：OrdersForProductAs、OrdersForProductBs、OrdersForProductCs。すべての注文表には、1対多の関係がありCustomersます。

Payments支払いの詳細を内部に保持する別のテーブルもあります。しかし、ここでそれをどのように構成するかについて疑問があります。

複数の製品タイプがあり、顧客が複数の製品を同時に注文する可能性があるため、これら3つの注文テーブルをPaymentsテーブルに関連付ける必要があります。

もう1つの問題は、顧客が1種類の製品のみを注文する可能性があることです。したがって、PaymentsテーブルのFK列はである必要がありますnullable。

私の質問は、これらのnullableFKカラムが長期的には頭痛の種になるかどうかです。一般的に、テーブルにNULL入力可能FK列を設定することは悪い習慣と見なされますか？

— ツベルク
ソース

2

これらのFKの少なくとも1つがnullにならないように、チェック制約を含めるようにしてください。

— Damien_The_Unbeliever

3

1つのNULL入力可能外部キーは多すぎます。

— nvogel

13

なぜあなたはOrdersForProductXテーブルを持っているのか疑問に思うでしょう。
あなたが尋ねたFK問題は、設計することができる可能性があります...

これらのテーブルの構造が同じ場合ProductType、何らかのOrderProductテーブルに列が必要になります。次にPayment、1つのFKを使用してリンクします

テーブルの構造が異なる場合、いくつかの共通の属性があると思います。したがって、共通OrderProductテーブルを作成してから、製品タイプごとに特定の子テーブルを作成できます（以下を参照）繰り返しPaymentますが、1つのFKを持つcommoneテーブルへのリンクだけです

これは「スーパーキー/サブタイプパターン」です

UQ1は、サブタイプテーブルで外部キーを使用する「スーパーキー」です。
各サブタイプテーブルには、複合PKとFKがあります (OrderID, ProductType)
各サブタイプテーブルには、そのテーブルのタイプを制限するためのCHECK制約があります

ご注文

OrderID、PK、UQ1
ProductType、UQ1
CommonThing1
...

OrderProductA

OrderID、PK、FK
ProductType、PK、FK、CHECK ProductType = A
ProductAThing1
...

OrderProductB

OrderID、PK、FK
ProductType、PK、FK、CHECK ProductType = B
ProductBThing1
...

— GBN
ソース

4

@tugberk：NULLこのアプローチではFKカラムがないことに注意してください。

— ypercubeᵀᴹ

「これらのテーブルが同じ構造を持つ場合」それらは同じ構造を持ちません。

— タグバーク

5

null許容の「外部キー」は避けてください。それらには複数の欠点があります。

外部キーにnullが含まれている場合、参照行の制約は常に適用されるとは限りません。ただし、そのデフォルトの動作は、異なるDBMS間で一貫していません。一部のDBMSは、null許容外部キーの動作を変更する構成オプションをサポートしていますが、サポートしていないものもあります。そのため、SQL開発者とユーザーは、データ整合性の観点から、null可能外部キー制約が実際に何を意味するのか不明確になる場合があります。DBMS製品間、または同じ製品を使用する異なるサーバー間でデータベースを移植すると、一貫性のない結果が生じる可能性があります。

データベース設計ツール、統合ツール、およびその他のソフトウェアは、それらを常に正しくサポートしているわけではなく、それらが生成する結果が間違っている可能性があります。

外部キーは、結合やその他のクエリロジックで頻繁に使用され、特定のDBMSによって適用されているロジックが適用されていない場合や適用されていない場合に、制約が有効であると考えるユーザーの問題を悪化させます。

クエリの書き換えやその他の最適化を許可する一部のクエリ最適化機能は、外部キーがNULL可能の場合は利用できない場合があります。

論理的には、null許容の「外部キー」制約はあまり論理的ではありません。SQL標準によれば、このような制約は、参照されるテーブルが空であっても違反されない可能性があります。これは、nullを使用するもっとも一般的な正当化の主張の1つ、つまり「不明」なケースを表しているということと矛盾しています。Xの有効な値がない場合、「不明な」Xは確かに有効な値になることはできません。しかし、SQLはそれを許可します。

Nullable外部キーは完全に不要です。外部キーを常に新しいテーブルに分解するか、スーパータイプ/サブタイプパターンを使用して、nullが不要になるようにすることができます。したがって、単純さと正確さのために、nullを入れるよりも、nullを残す方が良いです。

— nvogel
ソース

2

nullable FKカラムを使用するのが悪い習慣だとは聞いたことがない。それらは、別のテーブルを参照するが、埋められない可能性のある列（つまり、オプションのデータ）に最適です。

（なぜそれが問題になると思いますか？）

— スタイルズクライシス
ソース

ありがとう！まあ、それについてはよくわかりませんが、数年前にそのようなプロジェクトをしていて、何かに頭痛がしていたことを覚えています。だから、あなたが見るように私は明確ではありません：私が質問をした理由は何ですか？