Document-oriented database (MongoDB?) and invoicing/ordering?

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 tran开发者_JAVA技巧sactions 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.

How does one capture an order in this world? Would an order just be a new document in an Orders collection?

Yes. That's the way these databases work.

Would order_item relate back to a product listed in another document?

It could. Depends on what you're doing.

Or is it assumed that order_item would be copied and inserted into the order document

Also possible. This works well for historical analysis and data warehousing.

and thus, perhaps, difficult to report the total of product sold over time?

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.

How does one work around lack of transactions and maintain integrity?

MongoDB has locks. http://www.mongodb.org/display/DOCS/How+does+concurrency+work.

It's not clear what you mean by lacking transactions.

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