2010-09-06 73 views
0

我有以下locations表:在這種情況下反規格化是否可接受?

---------------------------------------------------------- 
| ID | zoneID | storeID | address | latitude | longitude | 
---------------------------------------------------------- 

phones表:

----------------------- 
| locationID | number | 
----------------------- 

現在,請記住,對於任何給商店也可以是最多五個電話號碼,頂部。順序無關緊要。

最近我們需要添加另一個表,其中將包含商店相關的信息,其中還包括電話號碼。

現在,對於這個新表格不應用locationID,因此我們無法將電話存儲在上一個電話表中。

保持數據庫規範化最終需要2個新表和總共4個聯接來檢索數據。對其進行非規範化將使舊錶如下:

---------------------------------------------------------------------------------- 
| ID | zoneID | storeID | address | latitude | longitude | phone1 | ... | phone5 | 
---------------------------------------------------------------------------------- 

並且總共有2個表和2個連接。

我不喜歡data1,data2,data3字段,因爲它可能是一個巨大的痛苦。那麼,你有什麼看法。

回答

7

我認爲,值得一提的是,如果您確實存在性能問題,那麼您可以通過取消規範化來獲得性能,而如果只有則只有。我總是爲3NF設計,只有在絕對必要時纔會恢復。

這不是你做你的查詢看起來更好。任何體面的數據庫開發人員都不會害怕一個適度複雜的SQL語句,儘管我不得不承認我已經看到了一些讓我不寒而慄的多行語句 - 請注意,這些來自無法控制架構的客戶: DBA首先會重新設計架構以避免這種怪異現象。

但是,只要您對解規範所帶來的限制感到滿意,就可以做任何您想要的。這並不是因爲如果有3NF警察漫遊地球尋找違法:-)

立即限制(可能還有其他),我可以看到的帶是:

  • 你會被限制(最初,沒有模式更改)到每個位置的五個電話號碼。從你的描述看,你不會覺得這是一個問題。
  • 您將浪費存儲不必在那裏的數據。換句話說,每行都使用5個數字的空格,而不管它們實際擁有的是什麼,儘管這種影響可能是最小的(例如,如果它們是varchar和nullable的話)。
  • 查詢電話號碼的查詢會很複雜,因爲您必須檢查五個不同的列。不管那是你的一個用例,我不知道,所以它可能是不相關的。

你應該可能選擇一種方式或其他(雖然我不確定這是你的意圖)。如果我遇到一個在商店表和單獨的電話號碼錶中有電話號碼的架構,如果他們彼此不同意,則會特別惱火,如果他們不同意的話,那麼尤其是。即使當我去規範化,我傾向於使用插入/更新觸發器來確保數據一致性得以維持。

+1

+1強調數據庫設計的一致性 – 2010-09-06 01:02:52

+1

也許我必須坐下來重新考慮整個手機的情況。把所有的手機都放在一張桌子裏,而不是兩張或四張,最後好多了。而男人我討厭所有'SELECT data1,data2 ....'讓我覺得很骯髒。謝謝Pax。 – Ben 2010-09-06 01:09:45

+0

如果我可以多次投票... – 2010-09-06 01:16:52

0

只是嘗試將您的新表與舊的位置表關聯起來,因爲這兩個表代表您應該能夠找到的商店來關聯這兩個商店。如果你能做到這一點,你的問題就解決了,因爲你可以像以前一樣繼續使用電話表。

相關與老位置表的新表將幫助您超越獲得電話號碼

4

我想從一個錯誤的模型,您的問題造成的。

爲什麼你有位置ID和商店ID?一家商店可以佔用多個位置嗎? 電話號碼是否與地理位置相關聯?

只需通過StoreId關鍵一切,您的問題就會消失。

+0

是的,一個商店可以有多個位置,並且電話與位置相關,因此位置ID(用於電話)。 – Ben 2010-09-06 01:43:19

+1

在這種情況下,保持正確的標準化模型,並做三/四表加入!它只是更多的編碼,只要按鍵索引,它不會花費任何東西。 – 2010-09-06 07:25:21