12

我正在尝试弄清楚如何为我的系统最好地实现这一点......并且现在让我的头离开 RDBMS 空间......

我当前数据库的一部分有三个表：Show、ShowEntry 和 Entry。基本上 ShowEntry 是 Show 和 Entry 之间的多对多连接表。在我的 RDBMS 中认为这是非常合乎逻辑的，因为对 Show details 的任何更改都可以在一个地方完成，Entry 也是如此。

在基于文档的存储中反映这一点的最佳方式是什么？我确信没有一种方法可以做到这一点，但我不禁思考基于文档的存储是否适合这种情况。

仅供参考，我目前正在考虑实施 RavenDB。虽然关于一般 NoSQL 设计的讨论会很好，但更专注于 RavenDB 的讨论会很棒！

感谢：D。

4

3 回答 3

22

在文档数据库中建模多对多关系时，您通常将一组外键存储在一个文档中。您选择的文档很大程度上取决于您打算遍历关系的方向。以一种方式遍历它是微不足道的，以另一种方式遍历它需要一个索引。

以购物篮为例。确切地知道特定篮子中的哪些项目比哪些篮子包含特定项目更重要。由于我们通常在篮子到项目的方向上遵循关系，因此将项目 ID 存储在篮子中比将篮子 ID 存储在项目中更有意义。

您仍然可以使用索引以相反的方向遍历关系（例如查找包含特定项目的篮子），但索引将在后台更新，因此它并不总是 100% 准确。（您可以使用 等待索引变得准确WaitForNonStaleResults，但该延迟将显示在您的 UI 中。）

如果您需要在两个方向上立即 100% 准确，您可以在两个文档中存储外键，但您的应用程序必须在创建或销毁关系时更新两个文档。

于 2011-01-30T23:40:32.170 回答
7

这对解决我的问题大有帮助！

于 2011-01-26T23:05:52.337 回答
1

回答问题

NoSQL 中的多对多关系是通过其中一个实体上的一组引用来实现的。你有两个选择：

  1. Show有一个Entry项目数组；
  2. Entry有一个Shows 数组。

数组的位置由最常见的查询方向决定。要解析另一个方向的记录 - 索引数组（在 RavenDB 中它就像一个魅力）。

通常，两个实体上的两个数组相互指向会带来更多的悲伤而不是快乐。在最终一致的环境中，您正在失去单一的事实来源……它有可能破坏数据完整性。

查看这篇文章 - NoSQL 中的实体关系（一对多、多对多）。它从各个角度涵盖了实体关系，考虑了性能、运营成本、开发和维护的时间/成本……并为 RavenDB 提供了示例。

于 2021-01-19T11:38:04.990 回答