數據庫體系結構，列中的大多數空字段

Question

我在MySQL中有一個數據庫表，根據一項新功能，我們可以通過兩種方式實現-1.在同一個表本身中創建一個新列（可為空），這種方法的缺點是-該列將具有95- 98％的時間為NULL條目。 2.使用現有表的外鍵創建一個新表。

所以這兩種架構看起來像這樣-

1. table1 - <id, ..., new_column>

2. table1 - <id, ...>, table2 - <id, table1_id, ...>

第一種方法遵循非規范化方法，而第二種方法遵循規范化方法。 但是由於這是一個現實問題，所以有時可以采用非規范化方法。

我對數據庫設計的某些假設可能是錯誤的，您認為解決此類問題的更好方法是什么？

Answer 1

如果您可以提供特定的示例，這將非常有幫助-“我應該添加一個可能為空的列”不容易回答。

非常籠統，規范，直到你能證明你做別的事情。 設計數據庫的易讀性和防錯性； 添加額外的表所花的精力要比弄清楚為什么為什么當您更改一些意外忘記了非規范化的代碼時，您的應用程序突然在12個月內報告不正確的數據。

那么，此可空列是否是實體的屬性？ 不是所有的people有一個middle name屬性-完全合理的有一個空列。 還是因為方便而只是將其附加到實體上，但實際上不是屬性嗎？

例如，一個person可能有一個employer ，而該雇主可能有一個address ； 理想情況下，您將創建一個帶有address屬性的employer表； 連接employer_address到人可能會覺得自己像一個快捷鍵（我不關心除地址以外的任何-我永遠不需要知道有多少人為該雇主工作）。

這可能看起來像是您正在省力省力-但它的可讀性較差（因此將來的開發人員會想知道您為什么這樣做），易發生錯誤（您可能會為單個雇主獲得不正確或不一致的地址），並且更難更改未來（祝您好運，僅根據地址確定有多少人為給定的雇主工作）。

Answer 2

在這些情況下，“垂直分區”可能是有利的

• 通常，第二個表中的列會丟失，因此該表中的行較少。 注意：您可以使用LEFT JOIN獲得NULL 。
• 第二個表中的列很大，但很少使用。 進行SELECT *時有性能上的劣勢，有些列是TEXT / BLOB 。 垂直分區可以幫助您提高速度。 （在InnoDB中選擇適當的ROW_FORMAT實際上消除了這一優勢。）
• 最常見的查詢不需要第二個表的列。
• 你得 無需停機添加列。 根據MySQL / MariaDB版本，主表上的ALTER .. ADD COLUMN ..可能會長時間阻止其使用。

我懷疑這種方式只能拆分100個表格中的1個。 這會使讀者感到困惑，等等。我上面列出的好處很少，並且這些好處可能不足以證明這樣做是合理的。

第二個表將具有與主表相同的PRIMARY KEY ，但沒有AUTO_INCREMENT 。 這兩個表將沒有相同的輔助鍵。 並請注意，您不能在兩個表中都有包含列的復合索引。

如果新列是一堆“屬性”，例如在“商店”應用程序中，請考慮將它們放入JSON列中。 這是開放式的，但是很難與WHERE或ORDER BY一起使用。