ドキュメント指向データベースの概念が初めてで、注文と注文処理に関連する高度な質問がいくつかあります。
この世界の秩序をどう捉えるか。Orders注文はコレクション内の新しいドキュメントにすぎませんか? 別のドキュメントにリストされorder_itemている に関連しますか? productそれとも、それorder_itemがコピーされて注文ドキュメントに挿入されると想定されているため、product時間の経過とともに販売された合計を報告するのが難しいのでしょうか?
トランザクションの欠如を回避し、整合性を維持するにはどうすればよいですか
申し訳ありませんが、理解したいと思っていますが、私には非常に新しいです...これらすべての「もの」を「オブジェクト」としてカプセル化し、サーバーとクライアントなどの間でそれらを移動することは非常に魅力的です。全体像のすべきこととすべきでないことを概念化するための助けが必要です。
この世界の秩序をどう捉えるか。注文は Orders コレクションの新しいドキュメントにすぎませんか?
はい。それがこれらのデータベースの仕組みです。
order_item は、別のドキュメントに記載されている製品に関連付けられますか?
出来た。何をしているかによります。
または、 order_item がコピーされて注文ドキュメントに挿入されると想定されていますか
可能です。これは、履歴分析とデータ ウェアハウジングに適しています。
したがって、時間の経過とともに販売された製品の合計を報告するのはおそらく難しいですか?
時間の経過とともに販売された製品の合計を報告することは常に困難です.
今日、製品「23SKIDOO」は、23 リットル、オープンバルブ、ダブル ウィジェットを備えたフラミスタットです。
昨年、リコールが行われる前は、同じ製品が 23 リットルの閉弁式フラミスタットで、ウィジェットが 1 つしかありませんでした。
一昨年、同じ商品が22.5Lでした。
これらは「同じ」製品ですか？マーケティングではそれらをすべて「23SKIDOO」と呼んでいます。しかし、違いがあります。
単一の Product テーブルでは、これを正しく解決できません。次に人々が行うことは、すべて「23SKIDOO」ファミリーの一部である「23SKIDOO-B」および「23SKIDOO-PLUS」製品を導入できるように、製品ラインと製品ファミリーを発明することです。
製品ライン、製品ファミリ、およびその他のより空想的なグループ化は、製品が明らかに異なる場合でも、魔法のように無関係な製品をまとめて報告し、「時間の経過とともに販売された製品の合計」を提供するための回避策およびハックです。
製品を注文にコピーすると (無駄に思えますが)、一般的に使用される多くの回避策よりも履歴の忠実性を維持できます。
トランザクションの欠如を回避し、整合性を維持するにはどうすればよいでしょうか?
MongoDB にはロックがあります。 http://www.mongodb.org/display/DOCS/How+does+concurrency+work .
トランザクションが不足しているという意味が明確ではありません。
したがって、一般的な質問に答えるのは常に困難です。ただし、アプリケーションが実行すると予想される読み取りと書き込みのパターンを確認することをお勧めします。RDBMS スキーマ設計と同様に、特定のドキュメント設計にもトレードオフがあります。
これは、MongoDB 中心のスキーマ設計プレゼンテーションへのリンクです。これらのトレードオフと設計オプションのいくつかを理解するのに役立つ場合があります。
http://www.scribd.com/doc/47326395/MongoBoulder-Schema-Design