新的面向文档的数据库概念，并有一些与订单和订单处理相关的高级问题。
一个人如何在这个世界上捕捉到一个订单？订单是否只是Orders集合中的新文档？会order_item涉及到product另一个文件中列出的内容吗？还是假设order_item将被复制并插入到订单文档中，因此可能难以报告product随时间推移的总销售量？
如何解决缺乏交易并保持完整性
抱歉，虽然渴望理解，但对我来说很新……将所有这些待售的“东西”封装为“对象”并在服务器和客户端等之间移动它们听起来非常有吸引力……如果这确实是合理的。只需要一些帮助概念化大局的注意事项。
一个人如何在这个世界上捕捉到一个订单？订单是否只是 Orders 集合中的新文档？
是的。这就是这些数据库的工作方式。
order_item 是否会与另一个文档中列出的产品相关联？
它可能。取决于你在做什么。
还是假设 order_item 将被复制并插入到订单文档中
也是可以的。这适用于历史分析和数据仓库。
因此，也许很难报告一段时间内销售的产品总量？
总是很难报告一段时间内售出的总产品。
今天，产品“23SKIDOO”是一款 23l、开阀、带有双小部件的 framistat。
去年，在召回之前，同样的产品是一个 23 升的封闭阀 framstat，只有一个小部件。
在前一年，同样的产品实际上是 22.5 升。
这些是“相同”的产品吗？营销部门称它们为“23SKIDOO”。但也有区别。
单个产品表无法正确解决此问题。然后人们要做的是发明产品线和产品系列，以便他们可以推出“23SKIDOO-B”和“23SKIDOO-PLUS”产品，它们都是“23SKIDOO”系列的一部分。
产品线和产品系列以及其他更奇特的分组是变通方法和技巧，可以神奇地使不相关的产品一起报告并提供“随着时间的推移销售的总产品”，即使产品明显不同。
将产品复制到订单中（虽然看起来很浪费）可以比许多常用的解决方法保留更多的历史保真度。
如何解决缺乏交易并保持完整性？
MongoDB 有锁。 http://www.mongodb.org/display/DOCS/How+does+concurrency+work。
目前尚不清楚您所说的缺少交易是什么意思。
所以总是很难回答一个笼统的问题。但是，我鼓励您查看您希望应用程序执行的读写模式。某些文档设计需要权衡取舍，就像 RDBMS 模式设计一样。
这是一个以 MongoDB 为中心的模式设计演示文稿的链接。它可以帮助您了解其中一些权衡和设计选项。
http://www.scribd.com/doc/47326395/MongoBoulder-Schema-Design