面向文档的数据库（MongoDB？）和发票/订购？
不熟悉面向文档的数据库概念，并且有一些与订单和订单处理相关的高级问题。
如何捕获这个世界上的订单？订单只是 Orders 集合中的一个新文档吗？ order_item 是否会与另一个文档中列出的product 相关联？或者是否假设 order_item 将被复制并插入到订单文档中，因此可能很难报告随时间推移销售的 product 总量？
如何解决缺乏交易的问题并保持诚信
抱歉，虽然我很想了解，但对我来说很陌生......将所有这些待售“物品”封装为“物体”并移动，听起来很有吸引力它们在服务器和服务器之间就这样围绕着。客户等等……如果确实合理的话。只是需要一些帮助来概念化大局中该做什么和不该做什么。
New to document-oriented database concepts and have a few high-level questions related to orders and order processing.
How does one capture an order in this world? Would an order just be a new document in an Orders collection? Would order_item relate back to a product listed in another document? Or is it assumed that order_item would be copied and inserted into the order document and thus, perhaps, difficult to report the total of product sold over time?
How does one work around lack of transactions and maintain integrity
Sorry, very new to me though eager to understand...it sounds very appealing to encapsulate all these 'things' for sale as "objects" and move them around as such between server & clients, etc...if it's indeed plausible. Just need some help conceptualizing big picture dos and don'ts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的。这就是这些数据库的工作方式。
可以的。取决于你在做什么。
也是可能的。这对于历史分析和数据仓库非常有效。
报告一段时间内销售的总产品总是很困难。
如今，产品“23SKIDOO”是一款 23l、开阀、带双部件的 framistat。
去年，在召回之前，同一产品是一款 23 升、闭阀 framistat，只有一个小部件。
前一年，同样的产品实际上是 22.5 升。
这些是“相同”产品吗？营销部门将它们统称为“23SKIDOO”。但也存在差异。
单个产品表无法正确解决此问题。然后人们要做的就是发明产品线和产品系列，这样他们就可以推出“23SKIDOO-B”和“23SKIDOO-PLUS”产品，这些产品都是“23SKIDOO”系列的一部分。
产品线和产品系列以及其他更奇特的分组都是变通方法和技巧，可以神奇地使不相关的产品一起报告并提供“随时间推移销售的总产品”，即使产品明显不同。
将产品复制到订单中（虽然看起来很浪费）比许多常用的解决方法可以保留更多的历史保真度。
MongoDB 有锁。 http://www.mongodb.org/display/DOCS/How+does +并发+工作。
目前尚不清楚您所说的缺乏交易是什么意思。
Yes. That's the way these databases work.
It could. Depends on what you're doing.
Also possible. This works well for historical analysis and data warehousing.
It's always hard to report total product sold over time.
Today, product "23SKIDOO" is a 23l, open-valved, framistat with double widgets.
Last year, before the recall, the same product was a 23l, closed-valved framistat with only a single widget.
In a previous year, the same product was actually 22.5l.
Are these the "same" product? Marketing calls them all "23SKIDOO". But there are differences.
A single Product table doesn't resolve this correctly. What folks then do is invent product lines and product families so they can introduce the "23SKIDOO-B" and "23SKIDOO-PLUS" products which are all part of the "23SKIDOO" family.
Product lines and product families and other more fanciful groupings are workarounds and hacks to magically make unrelated products report together and provide a "total product sold over time" even though the products are clearly different.
Copying the product into the order (while it seems wasteful) can preserve more historical fidelity than many of the commonly-used workarounds.
MongoDB has locks. http://www.mongodb.org/display/DOCS/How+does+concurrency+work.
It's not clear what you mean by lacking transactions.
因此，回答一个通用问题总是很困难。但是，我鼓励您查看您期望应用程序执行的读写模式。某些文档设计需要权衡，就像 RDBMS 模式设计一样。
这是以 MongoDB 为中心的架构设计演示的链接。它可能会帮助您了解其中一些权衡和设计选项。
http://www.scribd.com/doc/47326395/MongoBoulder-Schema-Design
So its always hard to answer a generic question. However, what I would encourage you to do it look at the patterns of read and write you expect your application to perform. There are trade offs for certain document designs just like there are from RDBMS schema designs.
Here's a link to a MongoDB centric schema design presentation. It may help you to understand some of these trade off and options for design.
http://www.scribd.com/doc/47326395/MongoBoulder-Schema-Design