訂單，客戶和產品之間的關係？

Question

我想構建一個電子商務數據庫，但我不明白訂單，產品和客戶之間的關係。 有很多數據庫示例，但它們太複雜。有關於可能的表格和關係的簡單解釋或例子。

謝謝。

Answer 1

這是最簡單的形式，如果客戶可以有多個訂單和訂單可以爲多個產品：

的ORDER表中有關於訂單的日期和狀態信息。

ORDER ITEM表中包含有關訂購產品數量的信息。

比這更簡單的唯一方法是，如果您有一個業務規則限制，說明「我沒有跟蹤我的客戶從一個訂單到下一個」或「每個訂單隻針對一個項目」 。如果你確實有這些（不切實際的簡單？）規則，那麼你可以減少模型中的表的數量。

請注意，這個非常簡單的模型很快就會變得複雜得多，您想要的更加靈活和逼真。例如，添加定價，付款方式，付款或庫存會增加很多複雜性。

Answer 2

我有一個「手卷」電子商務系統。該企業有一個內部網絡+ MySQL服務器（典型的Ubuntu的LAMP）。雖然數據庫結構的設計沒有得到很好的優化，但它運行良好。

我們所用的表格爲： order_main ORDER_DETAILS order_payment

在這裏，有很多來自上面的理想模型「鏈接」的數據簡單地複製。該網站的前端簡單而愚蠢。客戶必須重新輸入每個訂單的數據。

在上述情況下，MySql通過由cron運行的php腳本或用戶交互進行更新。該網站的文件已從主電子表格更新，該電子表格將被處理以生成靜態HTML文件。所以平面文件可以被認爲是項目數據的主人或發起人。該網站生成了瞬時客戶數據，最終將這些數據輸入到Quickbooks中，後者運行整個業務流程。

訂單將駐留在網絡服務器上一會兒，直到內部LAMP服務器將其關閉。這種方法工作了大約7年（當我們去Magento時最終放棄了）。

稍後，項目級別被添加，整個UI圍繞MySql數據庫而不是電子表格平面文件創建網站。這花了我大約一年的時間來編寫代碼，我們用了大約2年的時間，而Magento的改進足以投入生產。現在，Magento運行業務流程並導出到Quickbooks是一種事後考慮（關於客戶體驗），而QB僅用於會計。我覺得不必依靠QB來獲得日常收入。