mongodb - 当嵌入不是答案时如何处理MongoDB中的多对多关系？

Question

这是交易。假设我们在 MongoDB 中有以下数据模式:

items :包含一些数据的大型文档的集合(它实际上是什么绝对无关紧要)。

item_groups :包含文档的集合，其中包含 items._id 的列表叫 item_groups.items加上一些额外的数据。

因此，这两者通过多对多关系联系在一起。但是有一件棘手的事情:由于某种原因，我无法将项目存储在项目组中，因此——正如标题所说——嵌入不是答案。

我真正担心的查询旨在查找包含某些特定项目的某些特定组(即，我为每个集合设置了一组标准)。事实上，它还必须说明每个找到的组中有多少项目符合标准(没有项目意味着未找到该组)。

到目前为止，我想出的唯一可行的解​​决方案是使用 Map/Reduce 方法和一个虚拟的 reduce 函数:

function map () {
    // imagine that item_criteria came from the scope.
    // it's a mongodb query object.
    item_criteria._id = {$in: this.items};
    var group_size = db.items.count(item_criteria);
    // this group holds no relevant items, skip it
    if (group_size == 0) return;

    var key = this._id.str;
    var value = {size: group_size, ...};

    emit(key, value);
}

function reduce (key, values) {
    // since the map function emits each group just once,
    // values will always be a list with length=1
    return values[0];
}

db.runCommand({
    mapreduce: item_groups,
    map: map,
    reduce: reduce,
    query: item_groups_criteria,
    scope: {item_criteria: item_criteria},
});

问题线是:

item_criteria._id = {$in: this.items};

如果 this.items.length == 5000 甚至更多怎么办？我的 RDBMS 背景大声呼喊:

SELECT ... FROM ... WHERE whatever_id IN (over 9000 comma-separated IDs)

绝对不是好去处 .

非常感谢你们的时间，伙计们!

我希望最好的答案是“你太蠢了，不要用 RDBMS 风格思考，使用 $its_a_kind_of_magicSphere 来自 MongoDB 的最新版本”:)

Answer 1

我认为您正在努力将域/对象建模与数据库模式建模分开。在尝试 MongoDb 时，我也为此苦苦挣扎。

为了语义和清晰起见，我将替换 Groups带字Categories
本质上，您的理论模型是“多对多”关系，其中每个 Item可以属于Categories , 和每个 Category然后可以拥有很多Items .

这最好在域对象建模中处理，而不是在 DB 模式中处理，尤其是在实现文档数据库 (NoSQL) 时。在您的 MongoDb 模式中，您通过使用顶级文档模型和嵌入的组合来“伪造”“多对多”关系。

对于来自 SQL 持久性后端的人来说，嵌入很难接受，但它 是 答案的重要组成部分。诀窍是决定它是浅还是深，单向还是双向等。

顶级文档模型

因为您的 Category文档包含自己的一些数据，并被大量 Items 大量引用。 ，我同意你的观点，将它们完全嵌入每个 Item是不明智的。

相反，同时对待 Item和 Category对象作为顶级文档。确保您的 MongoDb 模式为每个文件分配一个表，以便每个文档都有自己的 ObjectId .

下一步是决定嵌入的位置和数量……没有正确的答案，因为这完全取决于您如何使用它以及您的扩展目标是什么……

嵌入决策

1. 元素

至少，您的 Item对象应该具有其类别的集合属性。至少这个集合应该包含 ObjectId每个Category .

我的建议是将您与 Item 交互时使用的数据添加到此集合中。最经常...

例如，如果我想在我的网页上以网格形式列出一堆项目，并显示它们所属类别的名称。很明显，我不需要了解有关 Category 的所有信息。 ，但如果我只嵌入了 ObjectId，则需要第二个查询来获取有关它的任何详细信息。

相反，最有意义的是嵌入类别的 Name收藏中的属性(property)以及 ObjectId ，以便拉回 Item现在无需其他查询即可显示其类别名称。

要记住的最重要的事情是嵌入在您的 Item 中的键/值对象。 “代表”一个 Category不一定要匹配真实Category文档模型...它不是面向对象编程或关系数据库建模。

2. 分类

相反，您可能会选择单向嵌入，而没有任何 Item您的 Category 中的信息文档...或者您可以选择像上面一样为项目数据添加一个集合( ObjectId ，或 ObjectId + Name )...

在这个方向上，我个人倾向于不嵌入任何东西......如果我想要的话，很有可能Item我的类别的信息，我想要很多，而不仅仅是一个名称......并且深入嵌入顶级文档(项目)是没有意义的。我只会让自己查询数据库中的 Items 集合，其中每个集合都在其类别集合中拥有我的类别的 ObjectId。

呼......肯定令人困惑。关键是，您将有一些数据重复，并且必须根据使用情况调整模型以获得最佳性能。好消息是这正是 MongoDb 和其他文档数据库所擅长的……