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

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

选项1将所有地址列作为属性放在各个表上.在创建时将详细信息从供应商复制到PO.可能存储多个副本

选项2创建单独的地址表.从供应商和采购订单表到地址表有一个外键.只允许在地址表上插入和删除,因为更新可能会比您想要的更改.然后我会有一些计划任务,删除地址表中不再被任何东西引用的任何行,因此未留下未使用的行.也许对地址表中的所有非pk列也有一个唯一的约束来阻止重复.

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

编辑:我必须保留采购订单上的地址,就像发送时一样.此外,我建议它有点复杂,因为可能有一个传递地址和一个帐单地址(还有一堆其他表有地址信息).

过了一会儿,我会根据日期删除旧的采购订单.在此之后,我打算垃圾收集任何地址记录,这些记录不再被任何引用(否则感觉就像我在创建泄漏).

1> Eric Z Beard..：

---

我实际上将此作为我的面试问题之一.以下是一个好的开始:

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

和

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

和

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

这样,您的地址完全不知道它们的使用方式,您的实体(用户,帐户)也不直接了解地址.这完全取决于您创建的链接表(在这种情况下是UserAddresses,但您可以执行适合您模型的任何操作).

对于潜在大型数据库的一个有点矛盾的建议:继续将"主要"地址直接放在您的实体上(在本例中为Users表中)以及"HasMoreAddresses"字段.与仅使用上面的干净设计相比,它看起来很蹩脚,但可以简化典型用例的编码,而非规范化可以对性能产生很大的影响.

---

问题：如果用户/客户/公司有多个地址怎么办？例如，帐单和送货地址。您如何用这种结构针对一个用户想法存储两种地址类型？

2> Paul Sonier..：

---

备选方案2,毫无疑问.

需要记住的一些重要事项:设计的一个重要方面是向用户指示何时地址彼此链接.即公司地址与送货地址相同; 如果他们想要更改送货地址,他们是否也想更改公司地址,或者他们是否想要指定新的装货码头？这种东西,以及向用户呈现这些信息并以这种粒度改变事物的能力非常重要.关于更新,这也很重要; 为用户提供"拆分"条目的粒度.并不是说这种UI很容易设计; 事实上,这是一个婊子.但这非常重要; 任何不足之处几乎肯定会让你的用户感到非常沮丧和烦恼.

也; 我强烈建议保留旧的地址数据; 不要运行一个进程来清理它.除非您拥有非常繁忙的数据库,否则您的数据库软件将能够处理多余的数据.真.我看到的关于数据库的一个常见错误是试图过度优化; 你想要优化你的查询,但你不想优化你的未使用的数据.(同样,如果您的数据库活动非常高,您可能需要做一些事情,但几乎可以肯定的是,您的数据库在表格中仍然存在过多数据时仍能正常工作.)在大多数情况下,它实际上更有利简单地让你的数据库增长,而不是尝试优化它.(删除表中的偶发数据不会导致数据库大小的显着减少,

---

使用地址后,请勿出于任何原因对其进行编辑.如果您需要将某些内容更改为新地址,请查看该新地址是否已存在(并使用它)或插入新地址.然后尝试删除旧地址,但如果因为它仍在使用中而无法删除,请不要大惊小怪(没有错误).