我正在用 Mongo 编写一个 REST API，并且对整个文档建模策略很感兴趣。这似乎是一个非常分裂的问题，人们说先去规范化，然后再规范化，反之亦然。
我有兴趣了解 REST api 的资源结构如何影响基于文档的数据库的结构。似乎使用 REST api 资源结构，对所有内容（即位置、租户、事务）进行单独的集合几乎是有意义的，尽管这似乎与 Mongo 的好处之一背道而驰。
我的问题是如何在 NoSQL（特别是 Mongo）文档数据库中对 REST api 的资源进行建模。
问问题
1182 次
1 回答
3
答案是，有很多方法，具体取决于您要优化的内容。通常，您的文档模式的定义和集合的分离将取决于您对文档的特定用例是什么——您将如何使用您的数据？
要记住的一个重要概念是，集合之间的“连接”成本很高 - 基本上你从一个集合中获取一个外键并在另一个集合中进行另一个查找，这就是为什么反规范化通常有助于性能 - 如果它匹配你的用例。这就是 MongoDB 可能大放异彩的地方，尽管将来如果您的需求发生变化，您的文档结构可能需要发生巨大变化。
第二个关键考虑因素是 MongoDB 文档大小限制——我上次检查时大约为 16MB。以您的经典博客网站为例，其中包含博客文章集合。我们可以选择将评论存储为子文档，作为帖子文档中的数组。这样，您可以拥有一个用于 /posts/postID 的 REST API，将帖子文档返回给您，而无需在其他集合中执行任何“连接”或查找评论等操作。但是，如果您的帖子上有大量评论，那么您就会遇到问题，因此在这种情况下，您必须通过将评论分离到另一个集合中来规范您的数据。
因此，从数据库中检索的速度/易用性和文档存储的灵活性——如果您需要为将来更改文档的模式结构，是您在计划项目 API 时应该考虑的两个主要考虑因素。
问问自己，文档/集合 X 将如何使用？您什么时候需要从中检索数据？如果一个资源租户有一个“父资源”位置，并且访问位置是您真正需要租户的唯一时间，那么您无论如何都可以将租户的存储设计到位置架构中。但是，如果您需要能够自己查询租户，那么您可能希望将租户分成他们自己的集合。因此，没有正确或错误的方法来解决它，只需根据您计划如何使用数据来制定计划！
祝你好运！
于 2013-03-22T21:00:58.540 回答