爲什麼一張桌子上有太多的香味？

Question

最近我和其他一些開發人員討論過，表中有多少列或模型上的屬性過多是代碼味道。有些人認爲，具有太多屬性的模型做了太多事情，應該分割。 但是如果模型實際需要這些屬性呢？

讓我以users表爲例。

用戶可以具有 first_name，last_name，street_name，city，state，age等。 根據參數，我認爲street_name,city和state應該被移到不同的表中。我同意相關數據以這種方式組合在一起，但是如果應用程序使用他的地址查詢用戶，那麼不會是一個更昂貴的操作，因爲他們現在在2個表中？

那麼什麼是正確的方式來建模具有很多屬性的表？ （如果我們也考慮這些情況：當 1的行數要少 2行的數量將是巨大的）

Answer 1

專門使用您的address方案，如果您的設計應該滿足每個用戶多個地址或使用相同地址跟蹤/捕獲多個註冊，您會發現它非常有益。

或者，你可以考慮一個更通用的地址表的實現，你有一個通用的description場和type列標籤的行作爲一個特定的地址類型（例如email，house，office，spouse等）。

故事的寓意是這個故事的寓意是如果可能有多於一個的話，就有一個單獨的表。在規範化只設置時，有在跳躍的額外的表或兩個信息沒有好處就是：

1. 沒有太大變化，
2. 不出現超過一次或
3. 每一個主鍵實體更多必須擁有它。

Answer 2

這是一個相當跑位問題。在設計數據庫模型時，您經常只記住一件事：性能。你不會因爲看起來更好而拆分表格。你會做到這一點，例如

• 的時候可以減少冗餘
• 或提高併發性。

當不是所有的數據庫時，大多數記錄的大小也有限制。所以你可以拆分一張表來使數據庫能夠有效地存儲它。

設計課程完全不同。分裂課程沒有很大的性能影響，但是對維護有很大的影響。可維護性應該是主要關心的問題。

Answer 3

這不是「一張桌子上有太多屬性」的問題。這是一個「在一張表中將錯誤的屬性綁定在一起」的問題。表格的關鍵應與主題中的某個實體或關係相關。非關鍵屬性應該取決於（由其確定）關鍵字，整個關鍵字以及關鍵字。

這是所謂的「數據規範化」的簡單視圖。數據標準化有助於防止在數據庫的多個位置存儲相同的事實。這種有害的冗餘不僅浪費，而且還會導致與自身矛盾的數據庫。這是一個真正的痛苦。

將非標準化設計轉換爲標準化設計通常需要拆分表格。但不要隨意拆分表格。瞭解規範化規則。跟隨他們，直到你成爲足夠專家，知道何時忽視他們。