データベース設計：FKはNULLです - 良いか悪いですか？

Question

私のアプリケーションでサポートされているすべての可能なメッセージを保存する "メッセージ"テーブルがあるとします。たとえば、FBのようなアプリケーションでは、「メディアメッセージ」（写真、ビデオ、オーディオなど）、「メディアアルバムメッセージ」、「プライベートメッセージ」などがあります。これをモデル化する方法の1つは

です

Table: message 
- messag_id (PK) 
- user_id (FK, this is the sender of the message) 
- message 

TABLE: media_message 
- media_message_id (PK, receiver of the message implied by the owner of the media) 
- message_id (FK) 

TABLE: media_album_message 
- media_album_message_id (PK, receiver of the message implied by the owner of the media album) 
- message_id (FK) 

TABLE: private_message 
- private_message_id (PK) 
- message_id (FK) 
- user_id (FK, receiver of the message) 

... etc. 

メッセージの「タイプ」ごとに、ある種の「マッピングテーブル」を作成する必要があります。この作品のような

何か：

TABLE: message 
- message_id (PK) 
- receiver_user_id (FK) 
- sender_user_id (FK) 
- message 
- media_album_id (FK, NULL allowed) 
- media_id (FK, NULL allowed) 

私は、この設計で、私はまだ参照整合性を施行することができると思います。 media_album_idとmedia_idがどちらもNULLの場合、私はそれが "プライベート"メッセージ（またはアプリケーション層で類似のロジックを実装している）と考えることができます。下側は、それが下側であっても、使用されていない列が常に存在することです。それでは、もう一度、これはうまくスケールされます - 少ないジョインなど

思考？

Answer 1

悪いです。 null可能な「外部キー」は使用しないでください。彼らには複数の欠点があります。

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

データベース設計ツール、統合ツールおよびその他のソフトウェアは、それらを正しくサポートしているとは限りません。

外部キーは、ジョインやその他のクエリロジックで頻繁に使用され、制約がそうでない場合に効果があると思われるユーザーのために問題を複雑にします。

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

最後に、これは不要です。ヌルが必要ないように、いつでもテーブルを構築することができます。したがって、シンプルさと正確さのために、ヌルを入れておくのが良いです。

Answer 2

FKは、データ整合性を保証するために2つのテーブル間の参照制約設定です。 FKをNULLにすることはできません。 media_album_id & media_idがヌル入力可能な場合は、FKであってはいけません。