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