e-commerce - 注文、顧客、製品の関係は？

Question

eコマースデータベースを構築しようとしていますが、注文、商品、顧客の関係がわかりません。データベースの例はたくさんありますが、複雑すぎます。可能なテーブルと関係についてのより簡単な説明または例はありますか？

ありがとう。

Answer 1

これは、顧客が複数の注文を行うことができ、注文が複数の製品に対して可能である場合の最も単純なフォームです。

ORDERテーブルには、注文の日付とステータスに関する情報が含まれています。

テーブルには、ORDER ITEM注文された製品の数量に関する情報が含まれています。

これよりも簡単にする唯一の方法は、「注文ごとに顧客を追跡しない」または「各注文は 1 つのアイテムに対してのみ」というビジネス ルールの制限がある場合です。これらの (非現実的なほど単純化された?) ルールがあれば、モデル内のテーブルの数を減らすことができます。

この非常に単純なモデルは、より柔軟で現実的なものにしようとすればするほど、非常に急速に複雑になり始めることに注意してください。たとえば、価格設定、支払い方法、支払い、または在庫を追加すると、すべてが複雑になります。

Answer 2

私は「手巻き」の電子商取引システムを持っていました。ビジネスには、内部の web+mysql サーバー (典型的な ubuntu LAMP) がありました。データベース構造の設計は十分に最適化されていませんでしたが、うまく機能しました。

使用したテーブルは次のとおりです。

ここでは、上記の理想的なモデルからの多くの「リンクされた」データが単純に複製されました。Web サイトのフロント エンドはシンプルで馬鹿げていました。顧客は注文ごとにデータを再入力する必要がありました。

上記の場合、MySql は、cron またはユーザーの操作によって実行される php スクリプトを介して更新されました。Web サイトのファイルは、静的な HTML ファイルを生成するために処理されるマスター スプレッドシートから更新されました。したがって、フラットファイルは、アイテム データのマスターまたは発信元と見なすことができます。Web サイトは一時的な顧​​客データを生成し、最終的にビジネス プロセス全体を実行する Quickbooks に供給されました。

注文は、内部の LAMP サーバーが注文を引き出すまで、1 分間ウェブサーバーに残ります。この方法は約 7 年間有効でした (最終的に Magento に行ったときに放棄されました)。

その後、アイテム レベルが追加され、スプレッドシートのフラット ファイルではなく、MySql データベースから Web サイトを作成することを中心に UI 全体が構築されました。これをコーディングするのに約 1 年かかり、Magento が製品化できるほど改善されている間、約 2 年間使用しました。現在、Magento はビジネス プロセスを実行し、Quickbooks へのエクスポートは (顧客体験に関して) 後付けであり、QB は会計のみに使用されます。日々の収入を QB に頼らなくてもよくなったと感じています。