我正在创建一个公司拥有多个用户、客户等的系统。我无法决定是将“对象”(例如用户)制作为单独的集合还是公司文档的嵌入文档。
Company (Object) ->
Users (Object) ->
Profile (Object) ->
...attrs..
History (Object) ->
...attrs...
Customers ->
...attrs...
我现在陷入了关系数据库的思维定势,不确定使用 NoSQL 实现它的“正确”方法。你有什么想法?
当双重嵌入文档(如公司>用户->历史)变得非常大时会发生什么?
嵌入式文档方法(如果有的话)还有哪些其他缺点?同样,我偏向于关系型思维模式。
提前致谢。
最佳答案
http://www.mongodb.org/display/DOCS/Schema+Design有一些关于架构设计的建议,10Gen 成员也有各种介绍,例如:http://dl.dropbox.com/u/205597/sts/sts-04-2012-mongo-and-nosql-schema.pdf
考虑到公司中可能的用户数量和历史对象的可能数量,我认为您可能需要为其中的每一个单独的集合。
关于MongoDB 嵌套设计哲学,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9650407/