MYSQL和規范化：如何處理許多可選字段？

Question

我有一個個人資料頁面，上面有大約20個可選字段。 為了保持規范化，我必須創建20個不同的表，然后在其中進行20個JOINS的查詢。 這對我來說似乎有點過頭了。

這是最好的方法嗎？

你建議我保持標准化嗎？

Answer 1

一個很好的方法（雖然有點令人困惑，除非你知道發生了什么）使用相同的設計wordpress使用 - 據我記得它被稱為實體屬性值（感謝@Matt Fenwick）。 https://stackoverflow.com/tags/eav/info

基本的想法是，你有兩個表，而不是你的20個INNER JOIN表來存儲賠率和結束。 一個存儲您的實體（一個帖子在wordpress'案例中），第二個存儲您的所有可能性和結束 - 或者WP指向它的元數據。 您沒有每個數據點的列，而是有一個名稱列，一個用於值，一個用於此屬性適用的實體的ID。

通過這種方式，您可以節省大量的SQL，擴展期間的麻煩以及開始構建它所需的時間。 如果您需要為另一個房產提供服務，那么您只需將其與其他房產一起打包 - 不要破壞架構。

關於WP數據庫布局的更多細節（這里我主要考慮的是wp_posts和wp_postmeta表）： http ：//codex.wordpress.org/Database_Description

所以一個例子可能是（偽代碼，對不起）：

table: yourEntity
entityID  int, primary key, auto increment
title     varchar

table: yourEntityMeta
entityID  int, non-unique key
name      text
value     text

這樣，您可以為每個實體提供任意數量的屬性，對具有NULL值的未使用列和18個需要連接的表沒有限制或性能問題。

希望這可以幫助

注意：此問題的一個問題（在評論中由@ypercube指出）是使用這意味着您不能為每個屬性指定數據類型，即日期屬性將存儲為文本，如布爾值或int。 您也無法使用foriegn鍵鏈接到有效值表（感謝@Catcall）。 在沿着這條路走下去之前，你需要仔細考慮。

Answer 2

我只會將可空列用於可選字段。 該表將變得非常大，但是如此多的連接只會降低您的性能，我找不到這些字段應該歸一化的原因，如果它們屬於一個對象並且將一起更新。

Answer 3

如果選項字段是常量，請考慮使用ENUM（2-20個選項），但是這種方法有自己的缺陷。

如果您主要關心的是數據庫規范化，那么即使您有20個選項字段，也應該為每個選項字段分別設置“查找”表，這樣就不會存儲重復數據。

此外，如果您決定在將來更改選項，它將使您的表在將來更容易維護。

JOIN語句也不錯，MySQL可以在一個查詢中支持多達61個表。 我已經在我的這個問題中探討了這個話題。