對面向文檔的數據庫概念有新意，並且有一些與訂單和訂單處理有關的高級問題。面向文檔的數據庫（MongoDB？）和開票/訂購？
如何在這個世界捕捉訂單？訂單是Orders集合中的新文檔嗎？ order_item是否會與另一個文檔中列出的product相關聯？或者是否假設order_item將被複制並插入到訂單文檔中，因此可能難以報告隨時間推移銷售的product？
怎樣一個解決辦法缺乏交易，並保持正直
對不起，很新，我雖然渴望瞭解......這聽起來很吸引人封裝所有這些「東西」銷售爲一體的「對象「並將它們在服務器&客戶端等之間移動，如果這確實是合理的話。只需要一些幫助概念化大圖片的事情和不該做的事情。
一個人如何捕捉這個世界的秩序？訂單是訂單集合中的新文檔嗎？
是的。這就是這些數據庫的工作方式。
order_item是否會與其他文檔中列出的產品相關聯？
它可以。取決於你在做什麼。
或者是它假定order_item將被複制並插入到訂單文檔
也是可能的。這適用於歷史分析和數據倉庫。
因此，也許很難報告一段時間內銷售的產品總量？
隨着時間的推移，銷售總產品總是很難。
今天，產品「23SKIDOO」是一個23l，打開閥門，framistat與雙部件。去年，在召回之前，同樣的產品是一款23l，封閉閥門的framistat，只有一個部件。
在去年，同樣的產品實際上是22.5l。
這些是「相同」的產品嗎？營銷部門稱他們都是「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
有幫助，謝謝，還有很多我期待的內容。 – Meltemi 2011-02-04 23:12:13
現在，由於您深入探討了處理「產品」的方法，如果您有2-3種不同的產品目錄需要參考「相同」產品，您會做什麼？產品的部分（價格，尺寸等）*可能會有所不同，但可以想象產品名稱或描述中的更改可能需要複製到多個「文檔」中。我們現在正冒險走出面向文檔的數據庫的甜蜜點嗎？ – Meltemi 2011-02-04 23:20:55