MySQL數據庫結構：多列還是多行？

Question

我正在創建在線字典，爲此我必須使用三種不同的字典：日常術語，化學術語，計算機術語。我有樹選項：

1）創建三個不同的表，每個字典

2）與額外的列創建一個表中的一個表，即：

id term dic_1_definition dic_2_definition dic_3_definition 
---------------------------------------------------------------------- 
1  term1 definition 
---------------------------------------------------------------------- 
2  term2      definition 
---------------------------------------------------------------------- 
3  term3           definition 
---------------------------------------------------------------------- 
4  term4      definition 
---------------------------------------------------------------------- 
5  term5 definition        definition 
---------------------------------------------------------------------- 
etc. 

3）與創建一個表這取決於它額外的「標籤」欄和標籤所有我的條件的字典裏，即：

id term  definition tag 
------------------------------------ 
1  term1 definition dic_1 
2  term2 definition dic_2 
3  term3 definition dic_3 
4  term4 definition dic_2 
5  term1 definition dic_2 
etc. 

的術語，可以與一個或多個字典，但有不同的定義，比方說，一個在日常使用中的長期使用可能與IT領域的相同術語不同。這就是爲什麼term1（在我的最後）表格可以分配兩個標籤 - dic_1（id 1）和dic_2（id 5）。

將來我會添加更多的字典，所以可能會有超過三個詞典。我想如果我將使用選項2（附加列），我將在未來的一張桌子和許多列中獲得。我不知道它是否對性能不好。

在我的情況下，哪個選項是最好的方法？哪一個更快？爲什麼？任何建議和其他選項，不勝感激。

謝謝。

Answer 1

我想你應該有一個查找表爲你的字典類型

DictionaryType（DTID，DTName）

有另一個表對您而言

條款（TermID，TermName）

Then then your definition

定義（DifinitionId，TermID，Definition，DTId）

這應該起作用。

Answer 2

數據標準化。我會去與3，那麼你就沒有做任何花哨的查詢，以確定有多少定義適用每一個給定的期限

Answer 3

選項3聽起來像最合適的選擇您場景。它使查詢變得簡單一些，並且從長遠來看肯定更容易維護。

選項2絕對不是要走的路，因爲你最終會得到很多空值，並且對這樣的表寫入查詢將是一場噩夢。

選項1並不差，但在您的應用程序可以查詢它之前，必須欺騙要查詢哪個表，這可能是一個問題。

所以選項3將導致像簡單的查詢：

Select term, definition from table where tag = 'dic_1' 

你甚至可以創建另一個標籤表，以保持對標籤本身的信息。

Answer 4

2）創建一個額外的列

你絕對不應該使用第二個方法一個表。如果將來你決定要10本字典呢？你必須創建一個額外的10列這簡直是瘋了..

你應該做的是建立一個單一的表您所有的字典和單表的所有你的條件和單表對於所有的定義，這樣所有的數據都以邏輯方式組合在一起。

然後，您可以爲每個詞典創建一個唯一的ID，這是在術語表中引用的。然後，你需要的只是一個簡單的查詢來獲得特定字典的條款。

Answer 5

總是有「這取決於......」

話雖如此，選項2通常是一個不錯的選擇 - 無論是從純粹的角度看（數據標準化）和實際的角度 - 你必須改變表格定義添加一個新字典（或刪除舊字典）

如果您的主要訪問總是要查找匹配的術語，並且字典名稱（'everyday'，'chemical'，'geek'）是一個屬性，那麼選項3是有意義的。

如果另一方面您的訪問總是主要通過字典類型和術語，並且字典1很大但很少使用，而字典2..n很小但通常使用，則選項1可能更有意義（或者對於很少使用的字典，選項1a => 1表，對於大量使用的字典另一個表）......這是一個非常假設的情況！

Answer 6

您想基於字典類型獲取數據，這意味着字典類型是數據。

數據應該位於表格的字段中，而不是表格名稱或字段名稱。如果您沒有這些字段中的數據，那麼您的數據模型需要更改（如果數據可能），並且您需要動態創建查詢以獲取數據。

第一個選項使用字典類型作爲表名稱。

第二個選項使用字典類型作爲字段名稱。

第三個選項將字典類型正確放置爲字段中的數據。

但是，術語和標籤不應該是字符串，它們應該是定義術語和字典類型的表的外鍵。

Answer 7

我開發了類似的項目，我的設計如下。在不同的表格中存儲單詞，定義和詞典是一個靈活的選擇，特別是在將來添加新詞典的地方。

alt text http://img300.imageshack.us/img300/6550/worddict.png

Answer 8

你的數據庫結構應該包含數據結構本身不應該數據。這會立即排除選項2，除非您創建不同的表以便構建在不同字典上運行的單獨應用程序。如果他們被分享，那麼這是錯誤的做法。

選項1需要對數據庫進行修改並重新進行查詢以適應新詞典的添加。它也爲簡單的查詢增加了過多的複雜性，例如「這個詞有哪些字典？」

選項3這裏是最靈活和最好的選擇。如果你的數據增長太大，你最終可以使用數據庫端詳細信息（如表分區）來加快速度。

Answer 9

這裏的要求太模糊了，導致'接受的答案'完全被過度解決'。這些要求需要提供更多關於如何使用字典的信息。

這就是說，工作小提供;我會去＃3的變化。

• 如果字典將完全獨立使用，則1號字完全可行，並且提及共享字詞概念的唯一原因是它恰好是巧合的可能性。
• 溝2;它不必要地導致列中的NULL值，並且DB設計不喜歡那樣。
• 3號是最好的，但溝人工關鍵，並在Term + Tag的關鍵。除了造成重複條目可能性的人工鍵（按術語+標籤）。如果沒有其他表引用TermDefinitions，則關鍵是浪費;如果有的話;然後他們說（舉例）「我引用TermDefinition＃3 ... Uhhm，不管它是什麼：S」

簡而言之，在需求至今沒有提供任何指示需要比選項3更復雜。