对于多对多关系，使用关系数据库还是 nosql 更好? [英] For a many to many relationship is it better to use relational database or nosql?

问题描述

对于多对多关系，使用关系数据库还是使用nosql更好?

For a many to many relationship is it better to use relational database or nosql?

假设您有很多用户.每个用户都可以有来自同一个用户表的朋友.因此，它本质上是与自身的多对多关系.关系数据库中的多对多关系将创建第三个表.现在我想知道假设这个用户表像那里的数百万人一样巨大，那么假设每个人每个人都有超过 10 个朋友，那么第三个表将是巨大的.如下所示，在 nosql 中将朋友存储为 json 列表不是更有效(而且总体上更直观)吗?

Let's assume you have a bunch of users. And each user can have friends that are from the same users table. So it's essentially a many to many relationship to itself. Many to many relationship in relational database will create a third table. Now I was wondering assuming this user table is huge like millions of people in there, this third table would be thus be gigantic assuming let's say each person has more than 10 friends each. Wouldn't it be more efficient for friends(and just overall more intuitive) to be stored as a json list in a nosql as shown below?

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

所以这也是一个数据结构问题，所以如果我没记错的话，这将是 btree 与哈希表.

so this is also a data structures question so it would be btree vs hash table if I'm not mistaken.

推荐答案

为什么关系实现会巨大"?为什么你的结构会更有效率"?您正在做出许多毫无根据的假设，这些假设对您有好处.(学习一些关系基础知识.以及关系与 NoSQL 的关系.)

Why would a relational implementation be "gigantic"? Why would your structure be "more efficient"? You are making a lot of unfounded assumptions that it would be good for you to think about. (Learn some relational basics. And the relational take on relational vs NoSQL.)

重新直观"，当 U 加好友 F 时，明显的关系组织是一个表 Friended 保存行，其中...U 加好友 F".Friended(U,F) 简称.如果你想要U朋友x的Us，那就是Friended(U,x)中的行，即PROJECT U RESTRICT F x Friended中的行，即中的行code>PROJECT U (Friended WHERE F=x)，取决于你是想在逻辑、关系还是混合方面进行思考.你的查询是什么?在谓词和表方面使用关系接口不需要或排除任何特定的实现.整个 NoSQL 运动是用户和供应商对作为数据接口而非存储结构的关系模型缺乏理解的可悲结果.用于 NoSQL 用例的 DBMS 只需是在查询和实现中更好地支持任意类型的关系 DBMS.

Re "intuitive", the obvious relational organization for when U friended F is a table Friended holding rows where... "U friended F". Friended(U,F) for short. If you want Us where U friended x, that's the rows where Friended(U,x), ie the rows in PROJECT U RESTRICT F x Friended, ie the rows in PROJECT U (Friended WHERE F=x), depending on whether you want to think in logic, relations or a mix. What's your query for that? Using a relational interface in terms of predicates and tables does not require or preclude any particular implementations. The entire NoSQL movement is a sad consequence of lack of understanding by users and vendors of the relational model as interface to data, not as storage structure. A DBMS for a NoSQL use case needs only to be a relational DBMS better supporting arbitrary types in querying and implementation.

根据我对可调整的版本化图形数据库的回答:

在给定时间的状态与具有给定模式的关系数据库之间存在明显的 1:1 对应关系.因此，随着时间的推移，您的状态集与变化模式数据库之间存在明显的 1:1 对应关系，即一个变量，其值为数据库加元数据，由 DDL 和 DML 更新命令操作.因此，没有证据表明您不应该只使用关系 DBMS.

There is an obvious 1:1 correspondence between your states at a given time and a relational database with a given schema. So there is an obvious 1:1 correspondence between your set of states over time and a changing-schema database, ie a variable whose value is a database plus metadata, manipulated by both DDL and DML update commands. So there is no evidence that you shouldn't just use a relational DBMS.

关系型 DBMS 允许在一定的计算复杂度和一定的优化机会下自动实现通用查询.任何应用程序都可以有专门的查询，使专门的数据结构和运算符成为更好的选择.但是您必须设计您的应用程序并了解这些特殊方面来证明这一点.实际上，由于您的状态和关系状态之间存在明显的对应关系，因此这是不合理的.

Relational DBMSs allow generic querying with automated implementation at a certain computational complexity with certain opportunities for optimization. Any application can have specialized queries that make a specialized data structure and operators a better choice. But you must design your application and know about such special aspects to justify this. As it is, with the obvious correspondences between your states and relational states, this has not been justified.

仅仅因为您可以使用图形绘制应用程序状态的图像并不意味着您需要图形数据库.重要的是您将评估哪些专门的查询/表达式.您应该根据您的问题域了解这些是什么，这可能是通过一些专门的数据结构和运算符以及关系最容易表达的.然后，您可以将表达和计算需求与专门的数据结构、关系表示和特定图形数据库的模型进行比较.

Just because you can draw a picture of your application state as of some time using a graph does not mean that you need a graph database. What matters is what specialized queries/expressions you will be evaluating. You should understand what these are in terms of your problem domain, which is probably most easily expressible per some specialized data structure and operators and relationally. Then you can compare the expressive and computational demands to a specialized data structure, a relational representation, and the models of particular graph databases.

当然，我们使用优化的特殊运算符和存储的专门应用程序.但这值得证明，并且从关系的角度来看，应该得到可扩展的关系 DBMS 的支持.

Of course there are specialized applications where we use optimized special operators and storage. But that merits justification, and from a relational perspective should supported by an extendible relational DBMS.

这篇关于对于多对多关系，使用关系数据库还是 nosql 更好?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！