这是在关系数据库中建模地址信息的好方法吗？

Question

我想知道这是不是一个好的设计。我有许多表格需要地址信息(例如街道、邮政编码/邮政编码、国家/地区、传真、电子邮件)。有时相同的地址会重复多次。例如，可以针对供应商存储地址，然后将地址存储在发送给他们的每个采购订单上。然后，供应商可以更改他们的地址，任何后续的采购订单都应该具有新的地址。它比这更复杂，但这只是一个示例需求。

选项1将所有地址列作为属性放在各个表中。创建采购订单时，将详细信息从供应商复制到采购订单。可能会存储多个

选项2创建单独的地址表。有一个从supplier和purchase order表到address表的外键。只允许对地址表执行insert和delete操作，因为更新可能会超出您的预期。然后，我将执行一些计划任务，从address表中删除任何不再被引用的行，这样就不会留下未使用的行。也许对address表中的所有非pk列也有一个唯一的约束，以阻止重复。

我倾向于选择2.有没有更好的方法？

编辑:我必须保持采购订单上的地址与发送时的地址相同。此外，我提出的建议有点复杂，因为可能有一个送货地址和一个帐单地址(还有一堆其他表包含地址信息)。

一段时间后，我将根据日期批量删除旧的采购订单。在此之后，我打算垃圾收集任何不再被任何东西引用的地址记录(否则感觉就像是在制造泄漏)。

Answer 1

实际上，我把这个作为我的面试问题之一。下面是一个很好的起点：

Addresses
---------
AddressId (PK)
Street1
... (etc)

和

AddressTypes
------------
AddressTypeId
AddressTypeName

和

UserAddresses (substitute "Company", "Account", whatever for Users)
-------------
UserId
AddressTypeId
AddressId

这样，您的地址完全不知道它们是如何使用的，并且您的实体(用户、帐户)也不会直接知道任何有关地址的信息。这完全取决于您创建的链接表(在本例中为UserAddresses，但您可以执行任何适合您的模型的操作)。

对于潜在的大型数据库，有一个有点矛盾的建议:直接在实体上放置一个“主”地址(本例中在Users表中)和一个"HasMoreAddresses“字段。与仅使用上面的干净设计相比，这似乎很麻烦，但可以简化典型用例的编码，并且反规范化可以对性能产生很大影响。

Answer 2

选择2，毫无疑问。

要记住一些重要的事情:当地址相互链接时，这是设计的一个重要方面。例如，公司地址与发货地址相同；如果他们想要更改发货地址，是否也要更改公司地址，或者是否要指定新的装货码头？这类东西，向用户提供这些信息并以这种粒度改变事物的能力是非常重要的。关于更新，这一点也很重要；为用户提供“拆分”条目的粒度。这并不是说这种UI很容易设计；事实上，它是一件很糟糕的事情。但这样做真的很重要；否则几乎肯定会让用户感到非常沮丧和恼火。

另外，我强烈建议保留旧的地址数据；不要运行进程来清理它。除非你有一个非常繁忙的数据库，否则你的数据库软件将能够处理多余的数据。真的。我看到的关于数据库的一个常见错误是试图过度优化；您确实希望优化查询的地狱，但您不想优化您的未使用的数据。(同样，如果您的数据库活跃度非常高，您可能需要一些东西来完成此任务，但几乎可以肯定的是，在表中仍有多余数据的情况下，您的数据库将正常工作。)在大多数情况下，简单地让数据库增长实际上比试图优化它更有利。(从您的表中删除零星数据不会导致数据库大小的显著减少，并且当它发生时…那么，由此导致的重新索引可能会对数据库造成巨大的消耗。)

Answer 3

您是否希望保留采购订单上原始地址的历史记录？

如果是，则选择选项1，否则将其存储在供应商表中，并将每个采购订单链接到供应商。

顺便说一句，糟糕的数据库设计的一个明确迹象是需要一个自动化的作业来保持数据的“清理”或同步。从这个角度来看，选项2可能是个坏主意。