2012-04-17 55 views
4

我有一個包含大約20個可選字段的個人資料頁面。爲了保持它的正常化,我必須創建20個不同的表格,然後用20 JOINS進行查詢。這對我來說似乎有點過分了。MYSQL和規範化:如何處理大量的可選字段?

這是最好的辦法嗎?

你是否建議我保持它正常化?

+0

所有加入的視圖? – 2012-04-17 14:27:08

+0

'可選'字段只是表示值可以爲空......不知道爲什麼您認爲這意味着20個附加表。 – Randy 2012-04-17 14:28:19

+1

@並注意到有多種規範化形式。您可能會發現預先確定您想要的是哪一個,以及決定性能,存儲空間,可維護性,適應性等的重要性。否則,你只是在黑暗中拍攝。 – 2012-04-17 14:30:44

回答

2

一個很好的方法來做到這一點(儘管有點混淆,除非你知道發生了什麼)使用相同的設計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)。沿着這條路線前,你需要仔細考慮這一點。

+1

http://stackoverflow.com/tags/eav/info – 2012-04-17 14:43:32

+0

@jammypeach所以基本上我保留所有的值在一列被逗號或類似的東西分隔? – 2012-04-17 14:46:28

+1

@jammypeach:不執行EAV的主要原因是您失去了完整性執行。在你的例子中,一切都是「文本」。 – 2012-04-17 14:47:09

0

如果選項字段是常量,請考慮使用ENUM(用於2-20選項),但是此方法有其自身的缺陷。

如果您主要關心的是數據庫規範化,即使您有20個選項字段,也應該爲每個選項字段分別設置「查找」表,以便不存儲重複數據。

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

JOIN語句沒有那麼糟糕,MySQL在一個查詢中最多可以支持61個表。我已在this question of mine中探討過該主題。

+0

是有道理的(我認爲enum與jammypeach所說的相同)。我會upvote它到1,但我已經upvoted從-1 lolll – 2012-04-17 15:22:46

+0

@AndyLobel哈哈,ty :) – Ozzy 2012-04-17 15:35:13

1

我只是使用可爲空字段的可選字段。表格會變得很大,但如此多的連接會降低性能,而且我無法找到爲什麼這些字段應該被標準化的原因,如果它們屬於一個對象並且會一起更新。