分層數據庫，多個表或具有父級ID的列？

Question

我需要在mysql數據庫中存儲有關挪威的縣，市和城市的信息。它們是以等級方式相關的（一個城市屬於一個又屬於一個城市的城市）。

是否最好將這個存儲爲三個不同的表並通過外鍵引用，還是應該將它們存儲在一個表中並將它們與parent_id字段關聯？

兩種解決方案的優缺點是什麼？ （兩個結構端效率明智）

Answer 1

三個不同的表：

• 更有效，如果你的應用大多訪問大約只有一個實體（縣，市，市）
• 業主成員的關係是明確的和優雅的模型信息;）

Answer 2

County，Municipality和City聽起來不像他們是同一種數據;所以，我會使用三個不同的表格：每個數據類型一個表格。

然後，我確實會在這些之間使用外鍵。

效率對講，不知道它會發生大的變化：

• 你會做的加入3個表，而不是加入同一個表的3倍;我想這是完全一樣的。
• 當您僅需處理這三種數據中的一種時，它可能會有所不同;但使用正確的索引，差異應該很小。

但是，從結構上講，如果這些是三種不同類型的實體，那麼使用三個不同的表格是有意義的。

Answer 3

我建議使用三個不同的表格，因爲它們是三個不同的實體。

在這些情況下，我只會使用一個表，您不知道層次結構的深度，但不是這種情況。

Answer 4

我會把它們放在三個不同的表中，只是因爲它是3個不同的概念。這會妨礙速度並會使查詢複雜化。但是，鑑於MySQL沒有對hirachical查詢（如Oracle的連接聲明）的任何特殊支持，無論如何，這些將變得複雜。

Answer 5

如果你確實得到了這三個級別（縣，市，市）的限制，我想你會對三個獨立的表格感到高興，並且外鍵每個都會達到一個級別。這會使查詢幾乎無法寫入。

通過引用同一個表的parent_id字段使用單個表，可以表示任意樹結構，但可以查詢從應用程序代碼中處理最佳的迭代過程，以提取從節點到根的完整路徑。

單獨的表格解決方案將更容易使用。

Answer 6

不同的表格：它只是「正確的」。我懷疑你會看到任何性能收益/損失，但這是一個正確的建模，預先可能會爲你節省很多麻煩。一方面，它將使SQL SELECT更容易編寫和讀取。

Answer 7

你會得到不同的意見回來給你，但我個人的偏好是有單獨的表，因爲他們是分開的實體。

實際上，您需要考慮您將對此數據進行的查詢，通常您的答案將來自於此。使用單獨的表格，您的查詢看起來會更清晰，並且最終不會保存任何東西，因爲即使它們是同一張表格，您仍然可以將表格連接在一起。

Answer 8

我會使用三個獨立的表格，因爲您確切知道您正在處理哪些類別的信息，並且不需要動態更改層次結構的「深度」。

它還會使數據更易於管理，因爲您只需知道表格即可知道數據是針對城市，市鎮還是縣（無需分辨「深度」首先是層次結構中的記錄！）。

既然你可能會自我加入來讓層次結構起作用，但我懷疑從一個表中獲取所有數據會有什麼好處。

Answer 9

在dataware住房申請，金博爾方法的擁護者可能將相同屬性表中這些字段：

create table city (
    id int not null, 
    county varchar(50) not null, 
    municipality varchar(50), 
    city varchar(50), 
    primary key(id) 
); 

的想法是，attibutes不應該超過l加入從事實表了。

我只是說這是一個替代視圖。我會親自去3桌設計。

Answer 10

這是'數據庫規範化'的一種情況，它是組織關係數據庫的字段和表以最小化冗餘和依賴關係的過程。目的是隔離數據，以便可以在一個表中添加，刪除和修改字段，然後通過定義的關係通過數據庫的其餘部分進行傳播。 如果任務分配給不同的開發人員，或者不同級別的用戶需要不同的權限來查看和更改數據，或者當您需要此類數據以用於其他目的時，小型表格可以提供幫助，則多個表格將有助於這種情況。 我的投票將用於多個表 - 數據分佈適當。