我正在用mongo编写rest api，对整个文档建模策略很感兴趣。这似乎是一个分裂性很强的问题，人们说先去规范化，然后再规范化，反之亦然。
我想看看rest api的资源结构如何影响基于文档的数据库的结构。似乎对于rest api资源结构，对所有东西（即位置、租户、事务）都有单独的集合几乎是有意义的，尽管这似乎有损于mongo的一个好处。
我的问题是如何在nosql（特别是mongo）文档数据库中建模rest api的资源。
最佳答案
答案是，有很多方法，取决于你想优化什么。
通常，文档模式的定义和集合的分离将取决于文档的特定用例是什么-您将如何使用数据？
要记住的一个重要概念是，集合之间的“连接”代价高昂——基本上，您是从一个集合获取外键，然后在另一个集合中执行整个其他查找，这就是为什么反规范化通常有助于提高性能——如果它与您的用例匹配的话。这正是MongoDB有潜力发挥的地方，尽管在未来，如果您的需求发生变化，您的文档结构可能需要显著改变。
第二个需要考虑的关键问题是MongoDB文档的大小限制——上次我检查时大约是16MB。
以你的经典博客网站为例，有一个博客帖子集。我们可以选择将注释作为子文档存储，作为post文档中的数组存储。这样，就可以为/posts/postid创建一个rest api，返回post文档，而不必在其他集合中执行任何“连接”或查找注释等操作。但是，如果你的文章中有大量的评论，你就会遇到问题，所以在这种情况下，你必须通过将评论分离到另一个集合中来规范化你的数据。
因此，从数据库中检索的速度/易用性和文档存储的灵活性（如果将来需要更改文档的架构结构）是在规划项目api时应该考虑的两个主要因素。
扪心自问，如何使用document/collection x？何时需要从中检索数据？如果一个资源租户有一个“父资源”位置，并且访问位置是您实际需要租户的唯一时间，那么您可以尽一切可能将租户的存储设计到位置架构中。但是如果您需要能够自己查询租户，那么您可能希望将租户分解为自己的集合。因此，没有正确或错误的方法去做这件事，只是你的计划的基础上，你打算如何使用你的数据！
祝你好运！