对于多对多的关系，最好使用关系数据库还是nosql？
我们假设你有很多用户。并且每个用户可以拥有来自同一用户表的朋友。因此，它本身就是多对多的关系。关系数据库中的多对多关系将创建第三个表。现在我想知道假设这个用户表是巨大的，就像那里的数百万人一样，这个第三个表格因此是巨大的假设，假设每个人每个人有超过10个朋友。如下所示，将朋友（以及整体更直观）存储为nosql中的json列表会不会更有效率？
{"user1": "friendslist":["user2","user3","user4"]}
{"user2": "friendslist":["user1","user3","user4"]}
{"user3": "friendslist":["user1","user2","user4"]}
{"user4": "friendslist":["user1","user2","user3"]}
所以这也是一个数据结构问题所以如果我没有弄错的话，它将是btree vs hash table。
答案 0 :(得分：0)
对于未受过训练的人来说，这似乎更直观。这就是为什么网络数据模型仍然如此普遍，即使关系模型已经存在了几十年。
“更好”取决于您希望如何使用它，“更高效”取决于数据库引擎，索引和各种其他因素。我更喜欢关系模型，因为我可以制定任何合理的问题，这些问题可以逻辑地从数据中得出并得到正确的答案。例如，如果我想找到朋友的朋友，我可以加入一个关系多对多表。我可以找到任何特定大小的周期和集团。我可以很容易地对朋友们宣布一个独特的约束。
没有关系数据库就可以做这些事情，但我怀疑它会如此简单或简洁。
数据库引擎使用的特定数据结构与关系概念无关，尽管它与效率相关。有关将使用哪种数据结构的更多信息，您需要查看特定的数据库管理系统及其存储引擎。
答案 1 :(得分：0)
为什么关系实施应该是巨大的＆＃34;？为什么你的结构会更高效？＃34;？你做了许多毫无根据的假设，认为这对你有好处。 （学习一些关系基础知识。关系与NoSQL的关系。）
重新＆＃34;直观＆＃34;，明显的关系组织，当U Fiended F是一个桌子Friended持有行......＆＃34; U Fiended F＆＃34;。 Friended(U,F)简称。如果你想要我们在哪里获得x，那就是Friended(U,x)的行，即PROJECT U RESTRICT F x Friended中的行，即PROJECT U (Friended WHERE F=x)中的行，这取决于你是否想要思考在逻辑，关系或混合中。那个你的查询是什么？在谓词和表方面使用关系接口不需要或排除任何特定实现。整个NoSQL运动是由于关系模型的用户和供应商缺乏对数据接口的理解而不是存储结构的悲哀结果。用于NoSQL用例的DBMS只需要是一个关系DBMS，可以更好地支持查询和实现中的任意类型。
从我对Adjustable, versioned graph database的回答：
在给定时间的状态与具有给定模式的关系数据库之间存在明显的1：1对应关系。因此，随着时间的推移，您的状态集与变更模式数据库之间存在明显的1：1对应关系，即一个变量，其值为数据库加元数据，由DDL和DML更新命令操纵。因此，没有证据表明您不应该只使用关系型DBMS。
关系型DBMS允许通过自动实现进行通用查询，具有一定的计算复杂性，并具有一定的优化机会。任何应用程序都可以使用专门的查询，使专用数据结构和运算符成为更好的选择。但是你必须设计你的应用程序并了解这些特殊方面以证明这一点。事实上，由于你们的州和关系国之间存在明显的对应关系，这是没有道理的。
仅仅因为您可以使用图表绘制应用程序状态的图片并不意味着您需要图形数据库。重要的是您将评估的专门查询/表达。您应该了解这些在您的问题域中的含义，这可能是最容易根据某些专业数据结构和运算符以及相关性表达的。然后，您可以将表达和计算需求与特定数据结构，关系表示和特定图形数据库的模型进行比较。
当然，我们使用优化的特殊运营商和存储的专业应用程序。但这值得称道，并且从关系角度来看，应该由可扩展的关系型DBMS支持。