數據庫設計父級子表vs多個表

我正在嘗試爲國家級城市頭創建父級子級關係。我考慮兩種approaches- 1）創建一個表 -數據庫設計父級子表vs多個表

 
pk| name    |  type  |  parent 
    1 | US    |  country  |  null 
    2 | UK    |  country  |  null 
    3 | California  |  state  |  1 
    4 | Los Angeles  |  city  |  3 
    5 | Kent    |  state  |  2 
    6 | Obama    |  president |  1 
    7 | Cameroon   |  pm   |  2

此表的主鍵，將引用另一個表，將記錄在一段時間對國家/城市/鄉村時期的人口增長。

2）第二種方法是爲國家，州，首長和城市創建多個表格，然後使用外鍵引用進行關係。然後，每個表（城市/州/國家）的主鍵將參考人口增長表

方法1是否有超過2的好處？查詢速度更快嗎？

來源

2012-05-02 Harpreet

一些城市跨越邊界。例如在美國，「得克薩斯州特克薩卡納」就是半個城市; 「阿肯色州特克薩卡納」是另一半。出於人口目的，這是一個單一的城市（實際上是一個單一的「大都市統計區域」）。爲了其他目的，它可能是兩個城市。我已經看到地理位置在一個縣的地理位置上，「在」第二個縣的緊急服務中，「在」還沒有第三個縣的非緊急服務。 –

方法1是一個EAV表，幾乎總是最糟糕的選擇，除非你完全無法預知你將需要什麼領域（例如定義你可能想要從各種醫學測試中存儲的各種東西）。對於那些不會改變的地理數據，我會避免像瘟疫這樣的選項1。查詢比較困難，會成爲阻塞爭用的來源，通常只是一個壞主意。

記住關係數據庫在以關係方式設計時工作得最好，在定義數據庫表時不要使用面向對象的思想。如果你真的需要EAV功能，至少應該在noSQl數據庫中進行更好的設計。

來源

2012-05-02 17:01:39 HLGEM

我認爲這取決於你想要在數據庫中存儲什麼（如果有的話）。例如，如果您想存儲特定國家/地區的數據，例如其他實體的「首都」等，那麼我會採用方法2。但是，如果您需要表示的是「人口羣體」，那麼1似乎很好並且更簡單。你的父母身份字段應該是一個外鍵，但是也應該是同一張桌子上父母的PK。我會考慮在類型表中輸入一個外鍵，這樣你就可以將它作爲一個數字而不是一個字符串存儲在你的主表中。只要你的鍵索引，我懷疑你會看到很多性能差異。

來源

2012-05-02 08:15:22

我不想要任何國家/城市的具體數據。我沒有太多的類型，所以我相信一個字符串應該沒問題。 – Harpreet

如果你的結構是剛性，請按照方法2.它可以讓你準確地定義參考完整性，所以你永遠不會有一個狀態（說）一個國家是國家的父母（而不是另一種方式）。另一方面，如果您預計動態添加其他類型的「節點」（如州或地區的州）和其他類型的關係（例如，有些國家可能根本沒有州，所以城市應該是直接「在」國家「下），那麼方法1的增加的靈活性可能證明參照完整性的」脆弱性「。

如果做得對，兩種方法在性能上應該表現得非常相似。

來源

2012-05-02 16:53:25

數據庫設計父級子表vs多個表

回答

相關問題