對於多對多關係，使用關係數據庫還是使用nosql更好？

Question

對於多對多關係，使用關係數據庫還是使用nosql更好？

讓我們假設你有一羣用戶。並且每個用戶可以有來自同一個用戶表的朋友。所以它本質上是一個多對多的關係。關係數據庫中的多對多關係將創建第三個表。現在我想知道，假設這個用戶表是巨大的，就像那裏的數百萬人一樣，那麼這個第三個表將會是巨大的，假設我們假設每個人都有超過10個朋友。對朋友來說，它是否更有效率（並且總體上更直觀）可以作爲json列表存儲在nosql中，如下所示？

{"user1": "friendslist":["user2","user3","user4"]} 
{"user2": "friendslist":["user1","user3","user4"]} 
{"user3": "friendslist":["user1","user2","user4"]} 
{"user4": "friendslist":["user1","user2","user3"]} 

所以這也是一個數據結構的問題，所以這將是B-樹VS哈希表，如果我沒有記錯。

Answer 1

對未受過訓練的人來說，這看起來更直觀。這就是爲什麼即使關係模型已經存在了幾十年，網絡數據模型仍然如此普遍。

「更好」取決於你想如何使用它，「更高效」取決於數據庫引擎，索引和各種其他因素。我更喜歡關係模型，因爲我可以制定任何合理的問題，這些問題可以從數據中邏輯派生並得到正確的答案。例如，如果我想找朋友的朋友，我可以加入一個關係型多對多表格。我可以找到任何特定尺寸的週期和派系。我可以輕鬆地聲明一對朋友的獨特約束。

在沒有關係數據庫的情況下做這些事情是可能的，但我懷疑它會如此簡單或簡潔。

數據庫引擎使用的特定數據結構與關係概念無關，儘管它與效率有關。有關將使用哪種數據結構的更多信息，您需要查看特定的數據庫管理系統及其存儲引擎。

Answer 2

爲什麼關係實現是「巨大的」？爲什麼你的結構會更「高效」？你正在做出很多毫無根據的假設，認爲這對你有好處。 （學習一些關係基礎知識，以及關係與NoSQL的關係）。

重新「直觀」，顯示關係組織爲什麼當你有一個友人F是一個表Frie Frie持有行在哪裏......「U friended F」。簡稱Friended(U,F)。如果你想讓我們在哪裏用友x，那就是Friended(U,x)的行，即PROJECT U RESTRICT F x Friended中的行，即PROJECT U (Friended WHERE F=x)中的行，這取決於你是否想在邏輯，關係或混合中思考。什麼是你的查詢那個？根據謂詞和表使用關係接口不需要或排除任何特定的實現。整個NoSQL運動是由關係模型的用戶和供應商作爲數據接口缺乏理解而造成的，而不是存儲結構。 NoSQL用例的DBMS只需要成爲一個關係數據庫管理系統，更好地支持查詢和實現中的任意類型。

從我的回答Adjustable, versioned graph database：

有一個明顯的1：你的國家之間在特定的時間和1的對應關係與給定模式的關係型數據庫。因此，隨着時間的推移，你的一組狀態與一個變化模式數據庫（即一個數據庫加元數據的變量，由DDL和DML更新命令操縱）之間存在明顯的1：1對應關係。所以沒有證據表明你不應該只使用關係數據庫管理系統。

關係數據庫管理系統允許在一定的計算複雜度下通過自動化實現進行通用查詢，並有一定的優化機會。任何應用程序都可以有專門的查詢，這些查詢可以使專門的數據結構和操作員有更好的選擇。但是您必須設計您的應用程序並瞭解這些特殊方面以證明這一點。事實上，你的狀態和關係狀態之間有明顯的對應關係，這是沒有道理的。

僅僅因爲你可以畫出你的應用程序狀態的圖片作爲使用圖形並不意味着你需要一個圖形數據庫一段時間。重要的是你將要評估哪些專門的查詢/表達。您應該瞭解這些問題是根據您的問題域來確定的，這可能最容易通過某些特定的數據結構和運算符以及關係來表示。然後，您可以將表達和計算需求與特定數據結構，關係表示以及特定圖形數據庫的模型進行比較。

當然有專門的應用程序，我們使用優化的特殊操作和存儲。但是這是值得稱讚的，並且從關係角度來看應該由可擴展關係數據庫管理系統來支持。