2010-02-27 89 views
1

我對兩個表之間的關係有疑問。mysql查詢正常關係表vs連鎖內部關係表

比方說,我們有一個表用戶和鏈接。

users 
+++++++++ 
id name 
1 name1 
2 name2 
3 name3 
+++++++++ 

links 
+++++++++ 
id link 
1 link1 
2 link1 
3 link1 
+++++++++ 

現在正常途徑這兩個鏈路與name_links表。 例如:

name_links 
++++++++++++ 
uid lid 
1 1 
1 3 
2 3 
2 1 
2 2 
3 2 
++++++++++++ 

現在我想知道,如果它是一個好主意,做一個表像這樣

name_links 
++++++++++++ 
uid lid 
1 1,3 
2 1,2,3 
3 2 
++++++++++++ 

優點和缺點我能想到的是:

PROS1:

您將始終在索引上搜索更快的查詢 示例select where uid = 1然後選擇鏈接1,3。兩者都是索引,所以它會是一個快速加載。

如果您有1000個用戶,並且他們每個人都有20個鏈接,這意味着您必須通過低谷20.000記錄才能獲得所有鏈接(我認爲,不確定這一點)。使用這種方法,你只需要一個索引,你就完成了。

cons1:

你將不得不更頻繁地更新name_links表,讀取,編輯和寫 例如用戶2刪除鏈接2的方法是:
+獲得的用戶串1
+從字符串中刪除數
+插入新的字符串這裏

一切都在索引完成,所以我認爲這將是快。

cons2:

另一個con是,當你刪除鏈接2,你有走線槽的所有字符串,但可以說這是不是太大的問題,因爲這不會經常發生。

這就是我到目前爲止所能得到的結果,而且我處於我的項目中,我必須決定要去哪個項目。

我很想就選擇哪種方法提供一些建議。我有我的優點和缺點嗎?有沒有我沒有考慮的事情。任何關於這個主題的幫助將不勝感激。

謝謝你們!

回答

3

非標準化的解決方案具有以下缺點:

  • 你不能有效地加入名稱和鏈接(FIND_IN_SET不是優化搜索)

  • 您不能強制使用參照完整性FOREIGN KEYs(在InnoDB

  • 刪除和添加名稱鏈接關係更復雜

如果您從不搜索給定鏈接的名稱並且鏈接數量很少,那麼您可能會因刪除額外連接而受益。

您應該確保性能優勢是真實的,您真的需要它,並且您意識到維護非規格化表格的複雜性。

如果links是固定的,則可以考慮使用本地SET數據類型。

0

絕對不應該連接記錄,除非你絕對必須。 考慮未來的能力,可以說你想要統計有多少用戶有鏈接3,這對你的第二種方法來說是一種痛苦。

所以我假設你的例子中這將是一個多對多的連接,這意味着一個鏈接可以連接到許多用戶,許多用戶可以連接一個鏈接。因此,您可能有與用戶連接到鏈接有關的屬性,如time_linked 這可能會出現在您的name_links表中。

0

我絕不是數據庫專家,但你的第二個選擇讓我想起很不好的想法。即使假設你永遠不需要通過name_link表中的鏈接進行搜索,但是對鏈接做任何事情都將是很多(不必要的,IMO)額外的工作。