數據庫設計：FK是NULL - 好還是壞？

Question

假設我有一個「消息」表，其中我想存儲我的應用程序支持的所有可能的消息。例如，在類似FB的應用程序中，可能存在「媒體消息」（例如照片，視頻，音頻），「媒體專輯消息」，「私人消息」等。對此進行建模的一種方式是：

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，那麼我可以假設它是一個「私有」消息（或者在應用層實現一些類似的邏輯）。不利的一面，如果它甚至是一個缺點，那就是總會有不使用的列。然後再次，也許這將擴大更好 - 少JOINs等

想法？

Answer 1

不好。避免可空的「外鍵」。他們有很多缺點。

上引用行的約束時外鍵包含空並不總是執行。但是，這種默認行爲在不同的DBMS之間並不一致。某些DBMS支持配置選項來更改可空的外鍵的行爲，有些則不支持。因此，SQL開發人員和用戶可能不清楚可空的外鍵約束實際上從數據完整性角度意味着什麼。在DBMS產品之間或使用相同產品的不同服務器之間移植數據庫可能會導致不一致的結果。

數據庫設計工具，集成工具和其他軟件不總是正確地支持他們和它們所產生的結果可能是錯誤的。

外鍵常用於連接和其他查詢邏輯，加劇了誰想到約束生效時，它不是用戶的問題。

從邏輯上講，一個可爲空的「外鍵」約束沒有多大的邏輯意義。根據SQL標準，即使被引用的表是空的，這種約束也不會被違反。這與使用空值的最常見理由之一相矛盾 - 它代表「未知」情況。如果沒有X的有效值，那麼任何「未知」X肯定不能成爲一個有效值 - 然而SQL將允許它！

最後，這是沒有必要的。您始終可以構造表，以便不需要空值。爲了簡單和準確，因此最好將NULL置於輸入狀態。

Answer 2

FK是2個表之間的參考約束設置，用於確保數據的完整性。說了這麼多，FK不能爲NULL。如果media_album_id & media_id可以爲空，那麼它們不應該是FK。