面向文档的数据库概念的新手，并且有一些与订单和订单处理相关的高级问题。
如何在这个世界中捕获订单？订单只是Orders集合中的新文档吗？ order_item是否会与其他文档中列出的product相关联？或者是否假设将order_item复制并插入订单文档中，因此，或许难以报告随时间推移销售的product的总数？
如何解决缺乏交易并保持诚信
对不起，虽然渴望了解但对我来说很新......听起来非常有吸引力将所有这些“东西”封装成“对象”并在服务器和服务器之间移动它们。客户等等......如果确实合理的话。只需要一些帮助概念化大图片注意事项。
答案 0 :(得分：2)
如何在这个世界中捕获订单？订单只是Orders集合中的新文档吗？
是。这就是这些数据库的工作方式。
order_item是否与其他文档中列出的产品有关？
可以。取决于你在做什么。
或者假设order_item将被复制并插入订单文档
也可以。这适用于历史分析和数据仓库。
因此，或许很难报告随时间推移销售的产品总数？
随着时间的推移，总是很难报告销售的总产品。
今天，产品“23SKIDOO”是一款23升，开放式阀门，带有双重小部件的framistat。
去年，在召回之前，同样的产品是一个23升，封闭式的framistat只有一个小部件。
去年，同样的产品实际上是22.5升。
这些是“相同”的产品吗？营销称他们都是“23SKIDOO”。但是存在差异。
单个Product表无法正确解析此问题。那时人们会发明产品线和产品系列，以便他们推出“23SKIDOO-B”和“23SKIDOO-PLUS”产品，这些产品都属于“23SKIDOO”系列产品。
产品系列和产品系列以及其他更奇特的产品组合都是变通方法和黑客，可以将不相关的产品一起报告并提供“随着时间的推移销售的总产品”，即使产品明显不同。
将产品复制到订单中（虽然看起来很浪费）可以比许多常用的解决方法保留更多的历史保真度。
如何解决缺乏交易并保持诚信的问题？
MongoDB有锁。 http://www.mongodb.org/display/DOCS/How+does+concurrency+work。
缺乏交易意味着什么并不清楚。
答案 1 :(得分：1)
因此，总是很难回答一般性问题。但是，我鼓励你这样做，看看你希望你的应用程序执行的读写模式。某些文档设计存在权衡，就像RDBMS模式设计一样。
这是一个指向MongoDB中心架构设计演示的链接。它可以帮助您理解其中的一些权衡和设计选项。
http://www.scribd.com/doc/47326395/MongoBoulder-Schema-Design