e-commerce - 订单、客户和产品之间的关系？

Question

我正在尝试构建一个电子商务数据库，但我不了解订单、产品和客户之间的关系。有很多数据库示例，但它们太复杂了。是否有关于可能的表和关系的更简单的解释或示例。

谢谢。

Answer 1

如果客户可以有多个订单并且订单可以针对多个产品，这是最简单的形式：

该ORDER表包含有关订单日期和状态的信息。

该ORDER ITEM表包含有关订购产品数量的信息。

比这更简单的唯一方法是，如果您有一个业务规则限制，即“我不跟踪我的客户从一个订单到下一个订单”或“每个订单只针对一个项目”。如果您确实有这些（不切实际的简单化？）规则，那么您可以减少模型中的表数量。

请注意，这个非常简单的模型开始变得越来越复杂，您希望它变得更加灵活和现实。例如，添加定价、付款方式、付款或库存都会增加很多复杂性。

Answer 2

我有一个“手卷”电子商务系统。该公司有一个内部 web+mysql 服务器（典型的 ubuntu LAMP）。虽然数据库结构的设计没有得到很好的优化，但效果很好。

我们使用的表是： order_main order_details order_payment

在这里，简单地复制了来自上述理想模型的许多“链接”数据。网站前端简单而愚蠢。客户必须在每个订单中重新输入他们的数据。

在上述情况下，MySql 是通过 cron 运行的 php 脚本或用户交互来更新的。该网站的文件是从一个主电子表格更新的，该电子表格将被处理以生成静态 HTML 文件。因此，平面文件可以被认为是项目数据的主文件或发起者。该网站生成了短暂的客户数据，这些数据最终被输入到运行整个业务流程的 Quickbooks 中。

订单将在网络服务器上驻留一分钟，直到内部 LAMP 服务器将其拉出。这种方法工作了大约 7 年（当我们去 Magento 时最终放弃了）。

后来，添加了项目级别，并围绕从 MySql 数据库而不是电子表格平面文件创建网站而构建了整个 UI。这花了我大约一年的时间来编写代码，我们使用了大约 2 年，而 Magento 改进到足以投入生产。现在，Magento 运行业务流程并导出到 Quickbooks 是事后的想法（关于客户体验），而 QB 仅用于会计。不必依赖 QB 来获得日常收入，我感觉好多了。