如何构buildMongo数据库的REST API
我正在用Mongo编写一个REST API，并被整个文档build模策略所吸引。 这似乎是一个非常分歧的问题，人们说先反规范化，然后正常化，反之亦然。
我很想看看REST API的资源结构如何影响基于文档的数据库的结构。 对于REST api资源结构来说，似乎对所有东西（即位置，租户，交易）都有单独的集合是有意义的，尽pipe这似乎是对付Mongo的一个好处。
我的问题是如何在NoSQL（特别是Mongo）文档数据库中对REST api的资源进行build模。
答案是，有很多方法，取决于你想要优化什么。 一般来说，定义你的文档模式和集合的分离将取决于你的文档的具体用例是什么 – 你将如何使用你的数据？
要记住的一个重要概念是，集合之间的“连接”代价高昂 – 基本上，您从一个集合中获得一个外键，并在另一个集合中完成另一个查找，这就是为什么非标准化通常有助于性能 – 如果匹配你的用例。 这就是MongoDB有可能发光的地方，但是如果您的需求发生变化，您的文档结构可能需要发生巨大的变化。
第二个关键的考虑因素是MongoDB文件大小的限制 – 上次大约16MB检查。 拿你的经典博客网站的例子，与博客文章收集。 我们可以select将注释存储为子文档，作为文档中的数组。 通过这种方式，您可以为/ posts / postID拥有一个其他API，将您的文章返回给您，而无需在其他集合中进行任何“连接”或查找以进行评论等操作。 但是，如果你的post上面有大量的评论，那么你就会遇到问题，所以在这种情况下，你必须通过将注释分隔到另一个集合来规范你的数据。
因此，从数据库中检索的速度和易用性以及文档存储的灵活性 – 如果您需要为将来更改文档的模式结构，则在计划项目API时应该考虑两个主要考虑事项。
问问自己，文档/集合X将如何被使用？ 你什么时候需要从中检索数据？ 如果一个资源租户有一个“父资源” 位置 ，并且访问位置是唯一真正需要租户的时间，那么通过一切方法，您可以将租户的存储devise为位置模式。 但是，如果你需要能够自己查询租户，那么你可能想把租户分解到他们自己的collections。 所以没有正确或错误的方法去做，只要根据你计划如何使用你的数据计划！
祝你好运！