这是一个场景。
您有一个向客户销售产品的电子商务网站。 明显有交易 例如对于每次销售，您都会记录有关销售的信息。 所以让我们有一个“购买”表。 它应该有哪些列？
1) 它应该只有一个使用“customer_id”的“客户”表的外键吗？ 或者 2) 保留快照，例如 'customer_name'、'customer_address'...都为 VARCHAR(x) 或者 3) 两者 或者 4）将“购买”表分成多个表？ 或者 别的东西。
请给出您的意见和原因。 干杯
【问题讨论】：
标签： database-design relational-database database-schema
如果时间是您的问题域的固有概念 - 对于电子商务，它也是 - 您也应该将其视为架构中的一流设计概念。
我的首选选项是在可以随时间变化的表格上设置“有效期”指示器。例如，客户表可能如下所示：
CUSTOMER
---------------
CustomerID pk
RecordVersion pk
Name
EmailAddress
HomeAddressID fk
HomeAddressRecordVersion fk
ValidFrom
ValidUntil
然后，“purchases”表通过指定 customerID 和 RecordVersion 列连接到 customers 表。这样，如果您想查看客户在下订单时使用的电子邮件地址，您可以从客户表中检索该数据。
您会知道客户使用过的其他电子邮件地址，不仅因为您可以在某些购买数据中找到它，还因为它是您客户记录的一部分。
此模型可能会变得非常复杂且难以查询 - 因此请谨慎使用。但特别是对于产品、价格、折扣、送货地址等来说，它非常有用，尤其是。在电子商务解决方案中。
【讨论】：
关于 Purchases 表应该包含的列在很大程度上取决于您的要求。通常，您至少会有某种购买代码、购买日期和购买客户，以及购买中的商品列表（单独的表格）。
关于您提到的选项，我猜您这里有一个关系数据库并且没有选择 NoSQL 解决方案。
在这种情况下，我会放弃选项 (2)。它不太适合关系模式，因为您可能会在多条记录中复制客户信息。出于同样的原因，我也会放弃选项 (3)。
选项 (1) 更适合关系数据库方法。您将进行购买，每个购买都与自己的客户相关联。这让你很容易知道：
如果您需要能够记录给定日期的客户数据，您始终可以选择创建客户历史记录表并将其链接到客户表。给定购买日期，您就可以知道购买时哪些客户数据是“活跃的”。
关于选项（4），我不知道你的意思，所以我无法回答。
HTH
【讨论】：