文档数据库设计：多级类别（特别是 MongoDB）
我正在尝试找出针对基于文档的数据存储系统考虑此问题的正确方法。我有一个两层类别系统的简单案例，其中有行业和行业组（例如管道和家庭服务）。
我的第一个想法是该文件将是行业组，并且其中包含行业，但问题是大多数相关数据将针对行业。我不确定文档中包含与子项目相关的数据是否“合理”。例如，一篇文章可能被分配给一个行业，而不是一个组 - 那么该参考文献看起来如何（假设链接来自非嵌套文档）？
不管怎样，对思考这个问题的正确方式有一些一般性的了解会很棒。
I'm trying to figure out the proper way to think about this problem for a document based data storage system. I've got the simple case of a two-tier category system, where there are Industries and Industry Groups (think Plumbing and Home Services).
My first thought was the document would be Industry Group and it would have Industries inside it, but the issue is that most of the related data will be to an Industry. I'm not sure if it's 'kosher' to have data relating to sub-items within a document. For instance, an article might be assigned to an industry, not to a group - so how does that reference look (assuming the link was from a non-nested document)?
Anyway, some general insight into the right way of thinking about this would be great.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
设计任何非关系数据库的最佳方法是基于您需要针对数据运行的查询，而不是数据本身。
您可以按照自己想要的方式设计非关系数据库，因为没有规范化规则有关系数据库。
回复您的评论：
您需要枚举所有查询数据的方式。然后决定在每种情况下哪种文档结构将使查询最方便。
由此，可能会出现一些模式。然后根据您的判断来决定选择哪种文档结构，以满足最大的查询横截面。
另请记住，在 MongoDB 中，冗余存储数据就可以了。事实上，推荐这样做是因为一种文档结构不太可能适合您的所有查询。您可能会发现一种文档结构对于大多数查询来说都非常好，但使最后一个查询变得不可能。这时您应该创建一个辅助的冗余文档集合来服务最后一个查询，因为所有其他查询都已处理完毕。
没有构建非关系数据库的规则。这使得它们比关系数据库更难。抱歉，NoSQL 是 TANSTAAFL 的一个例子！
The best way to design any non-relational database is based on the queries you need to run against the data, not the data itself.
You can design a non-relational database any way you want, because there are no rules of normalization as there are with relational databases.
Re your comment:
You need to enumerate all the ways the data will be queried. Then decide what document structure would make the query most convenient in each case.
From this, some patterns may emerge. Then use your judgment to decide which document structure to pick, that satisfies the greatest cross-section of queries.
Also keep in mind that in MongoDB, storing data redundantly is just fine. Recommended, in fact, because it's unlikely that one single document structure will be right for all your queries. You might find one document structure is pretty good for most of your queries, but makes the last query impossible. That's when you should create a secondary, redundant document collection to serve that last query, because all the other queries are taken care of.
There are no rules for structuring non-relational databases. This makes them harder than relational databases. Sorry, but NoSQL is a case of TANSTAAFL!