我正在为电子商务应用程序设计一个架构，其中有 3 个表，即订单、产品、客户。
那么我们是否应该立即将 customer_id 和 Product_id 存储在 Orders 表中。
这样做的限制是当产品或客户更新其属性(即产品价格或客户名称)时，订单表不会反射(reflect)它们。
例如:客户以 10 美元购买了产品，但后来产品价格更新为 20 美元。因此，现在当我们通过产品 ID 引用此订单时，我们会得到以 20 美元购买的结果，而不是10 美元。
解决方案 1:
一种解决方案是每当发生更新时就在产品表中插入一个新行，并对该产品执行软删除，以便可以从订单表中引用它。
解决方案 2:
将产品的大部分详细信息存储在订单表中，将客户详细信息存储在订单表中。
解决方案 3:
只要这些表有更新，就创建一个包含客户和产品的临时表。
我非常愿意接受任何其他建议。
最佳答案
您似乎缺少的一件事是 orderLineItem 表，除了最简单的解决方案(只有一个产品/订单)之外的任何其他解决方案。
话虽如此，您可以通过多种方式创建产品表。
假设价格是产品表中您想要更改的唯一变量，您可以有一个单独的 PricePoints 表，该表将存储任何给定时间任何商品的价格。然后，您可以在订单表中使用此表中的 ID，并使用它从产品表中获取产品 ID。存储此信息的稍微低效的方法(但检索速度更快)是将productId和pricePointId都存储在orders表中。
您还可以通过将支付的价格金额存储在订单表中来完成此操作。这使您可以更灵活地添加折扣和定价规则。如果您这样做，您确实需要担心审核价格。为什么此时这条线路要收取这个价格将成为一个常见问题。
您需要随时了解客户为产品支付了多少钱。如果客户今天购买该订单，了解他们会支付多少钱并不那么重要。
客户是一个稍微不同的问题。客户表中的一些信息是暂时的。其中一些必须针对订单进行修复。假设客户有姓名、地址、帐单地址和送货地址。订购时，送货地址和帐单地址必须绝对固定。您不想在三周后返回并发现送货地址已更改。但是，出于同样的原因，例如，如果客户更改了其婚前姓名，您可能希望更新名称。
现在，话虽这么说，我们不会为您设计架构。有很多关于如何设计简单的电子商务数据库的好资源。
关于mysql - 订单表的电子商务数据库设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17194408/