nosql 愿望清单模型 - 参考和嵌入文档之间的斗争

Question

我有一个关于使用 mongodb 和 mongoose 建模愿望清单的问题。这个想法是我需要一个用户能够拥有许多不同的愿望清单，其中包含许多愿望，每个愿望都引用一篇文章

我正在考虑它，因为愿望清单只属于一个用户，我认为为此使用嵌入式文档。

对于嵌入愿望清单的愿望蜜蜂也是如此。

所以我得到了类似的东西

var UserSchema = new Schema({
...
   wishlists: [wishlistSchema]
...
})

var WishlistSchema = new Schema({
...
    wishes: [wishSchema]
...
})

但我的问题是如何处理这篇文章？我应该使用参考还是应该将文章的数据复制到嵌入文档中。

如果我使用嵌入式文档，我会遇到更新问题。当文章的价格发生变化时，要更新每一个参考这篇文章的愿望变得很困难。但是访问那些愿望的文章是小菜一碟。

如果我使用参考，更新不再是问题，但是当我根据他们的文章标准过滤愿望时我遇到了问题（当我根据价格、类别等过滤愿望时......）。

我认为第二种方式可能是最好的，但我不知道是否可以构建一个查询来根据文章的字段过滤愿望。我使用人口尝试了很多东西，但是当您需要根据嵌套对象字段进行填充时，没有什么效果很好。 （例如在他们的文章响应某些条件时获得愿望）。

这种查询可行吗？

对于这个冗长的问题和我的英语不好：/但任何建议都会很棒！

Answer 1

根据我处理 NoSQL 数据库（主要是 mongo）的经验，在设计集合时，不要考虑关系。相反，请考虑如何显示、分页、 和检索文档。

出于多种原因，我更喜欢在发生更改时嵌入和更新多个架构，而不是进行引用。

1. 获取将快速简单，过滤不是问题（就像您说的那样）
2. 检索操作通常比更新更频繁地发生，并且通过适当的索引，您不必担心性能问题。
3. 它利用了 NoSQL 的无模式特性，并且由于需求变化（新排序、新过滤器等），您将不太容易进行重组
4. 分页会少很多麻烦，并且 UI 不会受到分页和限制的设计的限制。
5. 加入可能会变得昂贵。冗余数据更新起来可能很麻烦，但总比无法以特定方式显示数据要好，因为您的 schema 已标准化并且很难加入。

我会说经验法则是仅在不需要将它们显示在一起时才将它们拆分。加入他们也不是不可能，但肯定比较麻烦。