数据库设计，如何设置表

Question

我有一个简单的电子商务类型网站，用户可以为这些用户提供帐户，订单和联系人/结算信息。我只是想从效率和逻辑的角度来了解设置这些表的最佳方法。到目前为止，我基本上有两个不同的实体，用户和订单。用户将拥有名称和密码等基本帐户信息，订单将包含有关特定订单的所有信息。

我的问题是，我应该在用户表中包含所有联系人/帐单信息，还是制作两个单独的表来包含联系人和帐单信息？

Answer 1

您可能需要多考虑一下：

用户有联系方式和帐单邮寄地址，那么运费和其他地址呢？是否可以从一个公司拥有两个用户，每个用户具有不同的联系地址但具有相同的帐单地址？一个用户是否可以拥有他们在订购时选择的多个帐单邮寄地址？

然后，当您的订单出现时，如果客户更新其帐单邮寄地址，然后您在帐单邮寄地址更改之前提取订单，会发生什么情况。旧订单上的帐单邮寄地址是新订单还是订单时的帐单地址？

如果问题与您描述的一样简单，并且用户只是拥有联系人和帐单地址，并且没有其他“假设”，则将这些地址放在用户的表中是有意义的。但是，根据我在这个领域的有限经验，您可能会发现地址需要是独立的实体，与特定用户分开。实际上，您可能会将“用户”视为“联系地址”。

Answer 2

联系，结算和发货（如果需要）信息在逻辑上是分开的。从纯粹的规范化角度来看，地址应该是一个单独的实体，并且您应该在客户和地址之间建立关系。从标准化的角度来看，最“正确”的方法是在客户和地址之间建立多对多关系，并在计费，联系地址和送货地址之间区分一种类型（假设允许每个地址不止一个）

您还需要考虑您的产品。一种常见的方法是使用Order表，在其下面有一个Lines表（从Order到Lines的一对多关系）。每条生产线将引用单个产品，包括数量，价格和任何其他相关信息（折扣等）。产品表中的价格条目可以容纳简单的价格;更复杂的定价策略显然需要更多努力。

在有人说我走得太远之前：'简单'的网站经常发展。事先获得您的数据模型将为您带来无尽的痛苦。

Answer 3

我认为联系信息应该在用户表中，没有必要将其标准化为专用邮政编码表等。如果它们可能是信用卡号或类似的东西，它与账单信息相同。如果账单信息意味着某个计划，那么我会将不同的可用计划放入一个单独的表中，并用外键“链接”它。

Answer 4

如果您要查找同时联系和结算信息，并且您很少使用其中一个，那么将它们分成不同的表是没有用的无论如何都要加入他们。

另一方面，如果您经常只查找联系人或结算中的一个，那么性能可能会从分离中受益。

我个人不会将它们分开，因为我无法预见很多次我不想要它们。

Answer 5

您是否会遇到“用户”可能有多个联系人的情况？

我有数据库设计，其中“客户”可能有多个联系人，在这种情况下，您应该为联系人维护一个单独的表。否则，正如其他人所说，您可以将用户及其联系信息保存在同一个表中，因为您将始终一起查询它们。