数据库优化顺序

Question

在用户可以下单的数据库中，最好是有一个带有地址的新表，还是每个订单的头中都有地址数据。

Answer 1

这不仅与用户(及其地址)有关，还与您正在销售的产品的价格和其他信息有关，这些信息可以在下订单后更改，但订单本身必须保持不变。

一般来说，有两种方法可以做到这一点：

1. 复制订单(及其项目)中所需的所有内容。即使“主”数据发生更改，您仍然可以在顺序中保留一个副本。与this.

类似，

• “

• ”或"historize“整个数据库

(1)是更“实用”的方法，但可能会导致数据冗余(例如，当地址没有更改时，您仍然在制作它的单独副本)。

(2)是更“纯粹”的方法，但可能需要更多的JOINing，而且通常更复杂。

Answer 2

通常，您很可能希望将以下内容分开：

• Users
• Addresses
• Order信息

这是因为用户可以随着时间的推移更改地址，但旧地址需要保留，因为他们对它们有订单。此外，单个用户可以拥有来自同一地址的多个订单，因此我们将此信息分离出来，以减少重复。

http://en.wikipedia.org/wiki/Database_normalization

Answer 3

我想不出有什么理由让一个地址和一个订单在同一个表中，除了它现在为您节省了少量的工作。

使用单独的表的理由包括：

• 能够将多个递送地址与用户关联，而无需搜索所有订单(因此很容易为用户提供他们以前使用过的地址的下拉列表)。
• 您可以使用相同的表来存储帐单和递送地址，避免使用order

可以扩展/更改未来地址的存储方式(例如，在您进入国际市场时添加国家/地区字段)，而不必更新每个订单。

所有这些都与优化没有太多关系。不确定为什么会出现在标题中？

Branko在保存订单数据方面有一个很好的观点。但是，您不需要使数据库完全版本化。您可以简单地在订单中引用但不再具有当前值的内容(如用户和地址)上设置“过期”标志。换句话说，你只需要两个“版本”--当前版本和历史版本。只要您在order表中显式地引用(这样您就不需要通过用户转到交付地址，而是直接从order表链接到address表，这是可以实现的。完全控制数据库的版本，包括关系，是一项很大的工作。