數據庫：基於邏輯分組的可選列拆分錶
我一直在與我的管理層爭論拆分錶格。我更喜歡根據可以組合在一起的屬性將數據庫表拆分為多個表。始終未填寫且幾乎總是
Null（可選）的列。這是一個例子：
appointment- id (PK) - time - category - status - employee_id - visitor_id - optional_registration_time - optional_registration_message - optional_registration_feedback - optional_registration_image所有命名的列
optional_registration_*都是可選欄位。它們可能會或可能不會為每一行填寫。由於它們是可選的並且可以在邏輯上組合在一起，因此我的方法是將它們拆分到不同的表中。像這樣
appointment_registration:- appointment_id (FK) - time - message - feedback - image雖然這只是一個例子，但它幾乎解釋了我的困境。我更喜歡把它分開，但我的管理層堅持認為，因為它們屬於一起，它們應該在一張桌子上。我不同意僅僅因為它們屬於一起，並不意味著它們不能與不同的表相關聯。
通過拆分它們，新表
appointment_registration將只有合適的條目。桌子看起來很瘦。哪種方法更好？
在最嚴格的意義上，它們應該在自己的表中，因為它避免了列的可空性問題。並不是這些列中的任何一列都可以獨立地為 NULL - 它們是可選的，而不是 NULLable。
從技術上講，可以編寫一個檢查約束來確保強制執行該規則，但還有其他很好的理由將可選列分開：
- 數據模型中明確了它們的目的和作用
- 只需要引用可選列的查詢不必從主表中讀取
- 減少了對附加索引的需求
- 僅當存在可選列時才存在的任何關係都可以對可選表1使用 FK 約束
1想一想倉庫 - 我不希望更改庫存水平，除非採購訂單包含有關何時收到貨物的詳細資訊（日期、承運人、簽收人等）。因此，任何對庫存的調整都將引用進貨表的主鍵，而不是採購訂單表本身。
您要問的內容與術語database normalization鬆散相關。簡而言之，數據庫規範化是一種減少數據冗餘的方法，目的是提高數據的可靠性。出於其他原因，例如提高性能、更簡潔的設計、更好的可維護性（例如模式更改），有些人在表設計中遵循與規範化相同的通用方法。
我和你的心態差不多。我更喜歡將相關的數據點組合在一起，如果我有足夠多的數據點以至於它們幾乎特定於自己的對像類型，那麼我通常會設計我的數據庫以將它們建模為一個單獨的實體。遵循此設計模式還有助於防止您製作單片表。視圖可用於將儲存數據的表非規範化為可用於特定案例的中央實體。