【发布时间】：2024-04-20 22:05:01
【问题描述】：
我必须通过 NoSQL 引擎 (Couchbase) 管理文档之间的关系，我想出了这种方法来解决我的问题。这是我的解决方案以及让我意识到它的步骤：
我的问题是：
- 您对此解决方案有何看法？
- 你用过这样的东西吗？效果如何？
- 还有更好的想法吗？此解决方案的关键点应该会有所帮助
谢谢。
【问题讨论】：
标签： graph many-to-many relationship couchbase nosql
【发布时间】：2024-04-20 22:05:01
【问题描述】：
有趣的帖子 Matteo。阅读后我意识到您可以在以下几个方面进行改进：
考虑 1-1 节点关系。在您的帖子中，您专注于 N-N 节点 关系（当然可以说 1-1 是 N-N）...但是我认为有可能为 1-1 关系提供不同的（优化的）实现。对于 1-1，我使用节点密钥 值作为我的 json 文档中的一个字段（例如 user: {name:string, dob:date, 地址ID：字符串})
解决关系的节点密钥设计：您可以在密钥中进行编码 重视关系信息，例如键：“user#11”、“user#11#address#123”、“address#123#user#11”等
数据完整性方面：考虑缺少复杂的 交易。即您不能在一个文件中更改多个文档 交易。设计应该弥补这一点。
过去，我在 Couchbase 的模型设计中使用过类似的解决方案。它现在已经投入生产好几年了，它的性能很好（负载约为 250 tps）......我试图尽可能避免创建复杂的节点关系，最终只有很少的 1-1 和 1-N 类型.
【讨论】：
-
感谢您的努力，我的问题得到了答复。以下是我的考虑： 1. 好的 2. 好的，但我更喜欢不映射键内的逻辑 3. 当然，这是应用程序的工作；）
-
对于第 2 点。我认为您应该评估具有关系映射的键的优缺点。在某些情况下，我发现它非常强大的概念。例如，可以合成一个键来检索相关节点文档，而文档本身没有对该节点的引用。
我测试了这个解决方案并且效果很好。我喜欢“始终可能”的 N-N 关系的灵活性，因为您可以在需要时简单地添加关系文档，而无需更改应用程序逻辑。有一个缺点：您需要实现自己的应用程序逻辑约束以避免关系滥用。
我注意到，与 JSON 对象相比，使用数组并没有很大的优势，有时拥有其他关系数据可能很有用，例如关系的权重（或成本）。所以我建议你使用自己的类型的关系文档：
{
"type": "relationship",
"documents": ["key1", "key2"],
"all-the-data-you-need": { ... }
}
从性能来看，使用对象而不是数组并没有太大差异。
希望这对某人有所帮助！ ;)
【讨论】：