每个客户(Customer)都有一个物理地址和一个可选的邮寄地址。你希望如何建模这个问题?
选项1. 客户(Customer)有到地址(Address)的外键
客户(Customer) (id, phys_address_id, mail_address_id) 地址(Address) (id, street, city, 等等)
选项2. 客户(Customer)与地址(Address)之间有一对多关系，其中包含一个字段来描述地址类型
客户(Customer) (id) 地址(Address) (id, customer_id, address_type, street, city, 等等)
选项3. 地址信息被去规范化并存储在客户(Customer)中
客户(Customer) (id, phys_street, phys_city, 等等, mail_street, mail_city, 等等)
我的主要目标之一是简化对象关系映射，因此我倾向于第一种方法。您有什么想法？
出于规范化的常见原因，我更倾向于采用第一种方法。此外，这种方法还可以更轻松地对邮寄详细信息进行数据清理。
如果您可能要允许多个地址（邮件、住宅等），或希望能够使用有效日期，请考虑以下方法：
客户 (id, phys_address_id) 客户地址类型 (cust_id, mail_address_id, address_type, start_date, end_date) 地址 (id, street, city, etc.)
在考虑问题域时，您可能需要考虑一个重要的事实：人们会更改地址，并且可能希望提前告知您他们的地址更改；对于公用事业公司、电信公司等来说，这显然是正确的。
在这种情况下，您需要一种存储客户多个地址及其有效日期的方法，以便可以提前设置地址并在正确时间自动切换。如果这是一个要求，则变体（2）是建模的唯一明智方式，例如：
Customer (id, ...)
Address (id, customer_id, address_type, valid_from, valid_to)
Person (id, given_name, family_name, title, suffix, birth_date)
Address (id, culture_id, line1, line2, city, state, zipCode, province, postalCode)
AddressType (id, descriptiveName)
PersonAddress (person_id, address_id, addressType_id, activeDates)
许多人可能认为这有些过度了。然而，我们开发的应用程序中不可否认的共同主题是它们将拥有一些基本实体-人员、组织、地址、电话号码等等-并且它们都希望以不同的方式进行组合。因此，我们在前期建立了一些概括性内容，我们可以100%确定我们会用到这些内容。
地址表将遵循表分层继承方案，根据文化差异区分地址；因此，美国地址将具有州和邮政编码字段，但加拿大地址将具有省份和邮政编码。
我们使用单独的连接表来“给”一个人一个地址。这使得我们的其他实体-人员和地址-与其他实体没有联系，因为我们的经验是这倾向于使事情变得复杂。它还使得将地址实体连接到许多其他类型的实体（人员、组织等）以及与链接相关的不同上下文信息（例如我的示例中的活动日期）变得更加简单。
我更喜欢第一种方法。良好的标准化可以清晰地传达意图。该模型还允许使用相同的地址对象（行）用于两个地址，我发现这非常有价值。过度复制此信息很容易使人迷失方向。
选项3过于严格，选项1无法扩展以允许其他地址类型而不改变模式。选项2显然是最灵活的，因此是最好的选择。
我会选择选项1。如果您愿意，甚至可以稍微修改一下以保留地址历史记录：
Customer (id, phys_address_id, mail_address_id)
Address (id, customer_id, start_dt, end_dt, street, city, etc.)
Address表中添加一条新记录。 phys_address_id和mail_address_id始终指向当前地址。mail_address_id），如果物理地址和邮寄地址相同，则只需将phys_address_id和mail_address_id指向同一条记录即可。很好的帖子。我花了一些时间考虑最合适的架构，得出结论，quentin-starin的解决方案是最好的，但我已经在他的PersonAddress表中添加了start_date和end_date字段。我还决定添加notes、active和deleted。
deleted用于软删除功能，因为我认为不想通过从联接表中删除记录来丢失以前的地址信息。我认为这是相当明智的，其他人也可能要考虑这一点。如果不是这样做，就可能留给纸质或电子文档的修订来尝试跟踪地址信息（最好避免）。
notes我认为是一种要求，但这可能只是个人喜好。我在回填练习中花费了时间来验证数据库中的地址，有些地址可能非常模糊（例如农村地址），我认为至少允许在记录地址中保存关于该地址的注释非常有用。
我希望听取关于地址表唯一索引的意见（再次指的是quentin-starin示例中同名的表）。您认为应该强制执行唯一索引（可能跨越所有非空/必填字段的复合索引）吗？这似乎很明智，但仍然很难防止重复数据，因为邮政/邮编并不总是唯一的。即使国家、省份和城市字段是从参考数据中填充的（在我的模型中是这样），地址行中的拼写差异也可能不匹配。最好避免这种情况的唯一方法可能是从传入的表单字段运行一个或多个数据库查询，以查看是否已找到可能的重复项。另一个安全措施是给用户选择从已经链接到该人的数据库中选择地址，并使用它来自动填充。我认为这可能是一个只能明智地采取预防措施来防止重复，但接受它迟早会发生的情况。