Mongodb数据模型策略指导/build议
我刚刚开始与节点和mongodb，并试图了解如何最好地构造数据（来自一生的SQL）。
所以我已经结束了大部分embedded式的数据结构，我相信这些关系是合乎逻辑的，但是在兔子洞之前，我们需要一些外部的反馈信息！
这里是我提出的新的mongodb数据模型：
user name (string) email (string) avatar (string) password (string) newsletter (binary) account admins user (objectId) name (string) logo (string) sub (number) stripe (string) property users user (objectId) party (number) role (number) admin (binary) name (string) ecd (date) complete (binary) activity description (string) user (objectId) time (date) task_group position (number) name (string) task assinged user (objectId) complete (binary) name (string) description (string) due (date) visibility (number) comment user (objectId) time (date) comment (string) 以前（我正在重build一个现有的sql应用程序）有很多表格纯粹是为了桥接数据，即account_link连接用户与帐户（多对多）等现在已经embedded，允许一个稍微直观的结构。 鉴于embedded的数据只需要在其父项的上下文中进行访问，我认为这是一条路。
我担心的是，某些子文档会变得相当大。 我是否必须担心在子文档中包含多less数据？ 还是应该像处理表格一样对待子文档？ 即如果它发现每个task_group包含400,000个任务，那么这会不必要地“膨胀”一个property ？ 是否有一点，你分裂这个内容，创build“链接表”纯粹是出于实际/性能的原因？ 还是我只是坚持SQL思维，这只是感觉不对？
更新
鉴于收到和参考的build议，我相信我已经制定了一个更合适的devise，虽然正如其他地方已经提到的那样，但它更像是一门艺术而不是一门科学。 反馈仍然欢迎！
重要注意事项
我不会重新编写链接的博客文章，但要总结一下：
- 如果基数是一对多，并且不需要在父对象的上下文之外访问embedded对象，则embeddedN侧
- 如果基数是一对多的，或者N侧的对象应该由于任何原因而单独使用的话，请使用对N侧对象的引用数组
- 如果基数是一对一的话，则使用对N侧物体中的单侧的引用
我也考虑了其中一个答案中提到的增长/文档大小一致性。
USER name (string) email (string) avatar (string) password (string) newsletter (binary) ACCOUNT admins (USER reference array) name (string) logo (string) sub (number) stripe (string) properties (PROPERTY reference array) PROPERTY name (string) ecd (date) complete (binary) users user (USER objectId) party (number) role (number) admin (binary) activity description (string) time (date) task_groups (TASK_GROUP reference array) TASK_GROUPS property (PROPERTY objectId) position (number) name (string) task assigned user (USER objectId) complete (binary) name (string) description (string) due (date) visibility (number) comment user (USER objectId) time (date) comment (string)
看这张照片之前，我会解释他们：
集合中的每个文档在文档增长时都有自己的位置和空间，集合中没有足够的空间，留下的空闲空间例如你有后期收集，并embedded了集合注释
post { _id:ObjectId('101'); comments:[{author:'john',text:'some text'},{author:'mike',text:'some text'}] }
这个模型是非常有用的，当你只能添加一两个或三个评论不是很多，但是当你可以推送多达你需要的评论你必须写文档的参考将有后期收集和评论收集
后期收集文件：
{ _id:ObjectId('101') }
意见收集文件：
{ _id:ObjectId('10001'), _postId:ObjectId('101'),//references to post collection document! text:'some text', author:'john' }
1）模型一对一关系与2）与embedded式文档的模型一对多关系3）与文档引用的模型一对多关系
阅读全部三段
当embedded式文档变得相当大时，我只会说只有一个文档引用没有embedded
我甚至会把任务从任务组中分离出来，并把它归入任务的一个属性。 您可能想查询组中的每个任务。 只要你知道它属于哪个任务，你就可以做到这一点。
但是，你也可能想要find一个特定的任务，但是关于它所属的一个或多个组的信息可能仍然是相关的。 如果以这种方式在任务组中embedded任务，则会限制应用程序查看该任务可能属于哪个类别/组。可能这些组的function更像filter，在这些组中find具有此描述的任务。
当您考虑如何查询时，您可能想对这些结构进行的不同查询变得更加明显。 下一步是查询和build立您的模型索引。 如果你在embedded式文档上有一个索引，它应该是一个与原始文件相关的独立模型。 但这也取决于embedded文档依赖于上面的结构中的属性的多less。
TL;博士;
我发现一个常见的经验法则是，如果你做了大量的读取，而且embedded式文档的写入非常less，那么可以embedded。 沉重的写作和读，你会想要分开的embedded性。