Nosql多对多
在文档数据库设计中处理多对多关系的公认模式是什么?
What is the accepted pattern for handling many-to-many relationships in a document database design?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
在文档数据库设计中处理多对多关系的公认模式是什么?
What is the accepted pattern for handling many-to-many relationships in a document database design?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(2)
您想要如何对多对多进行建模取决于您想要提出什么样的查询、您想要如何更新数据等等...假设我们有与多对多方式的 bar 相关的 foo。
您可以将 foo 建模为
并将 bar 建模为
或者您可以将 foo 和 bar 之间的图表或关系建模为单独的文档本身
还有很多其他方法。您想要如何做到这一点取决于您想要提出的问题、您想要支持的操作、您想要提高效率以及数据库中可用的索引。
How you want to model the many-to-many will depend on what kind of queries you want to ask, how you want to update the data, etc... Say we have foos related to bars in a many to many fashion.
You could model a foo as
and model a bar as
Or you could model the graph or relations between foo and bar as individual documents themselves
There are plenty of other ways too. How you want to do it will depend on the questions you want to ask, the operations you want to support, what you want to be efficient, and the indexing available in the database.
假设我们讨论的是确实需要关系的情况,而不是仅仅因为 SQL 比复杂对象更好地处理关系而存在的情况,那么设计类似于 SQL 的标准设计 - 两个一对多关系。
主要区别在于您具有多值字段,因此每个文档中都有一个 id 列表,而不是使用第三个文档/表将单个连接记录为一对 id。
如果您遇到该列表太长的情况,您可能会考虑通过搜索索引比关系更好地处理某些内容。
Assuming we are talking about cases where a relationship is really necessary rather than the ones which only exist because SQL handles relationships better than complex objects, the design is similar to the standard one for SQL - two one to many relationships.
The key difference is that you have multivalue fields, so instead of a third document/table recording single connections as a pair of ids, you have a list of ids in each document.
If you run into cases where that list gets too long you are likely looking at something that would be better handled by search indexing than a relationship.