模拟客户< - >地址的最佳方式

Question

每个人Customer都有一个实际地址和一个可选的邮寄地址.你最喜欢的模型是什么？

选项1. Customer具有外键Address

   Customer   (id, phys_address_id, mail_address_id)
   Address    (id, street, city, etc.)

选项2. Customer具有一对多关系Address,其中包含用于描述地址类型的字段

   Customer   (id)
   Address    (id, customer_id, address_type, street, city, etc.)

选项3.地址信息被去规范化并存储在 Customer

   Customer   (id, phys_street, phys_city, etc. mail_street, mail_city, etc.)

我最重要的目标之一是简化对象关系映射,所以我倾向于第一种方法.你的想法是什么？

Answer 1

对于归一化的所有常见原因,我倾向于采用第一种方法.这种方法还可以更轻松地对邮件详细信息执行数据清理.

如果您可能允许多个地址(邮件,住宅等)或希望能够使用有效日期,请考虑这种方法

   Customer   (id, phys_address_id)
   Cust_address_type (cust_id, mail_address_id, address_type, start_date, end_date)
   Address    (id, street, city, etc.)

Answer 2

您可能需要考虑的一个重要事实(取决于您的问题域)是人们更改地址,并且可能希望在地址更改之前通知您; 这对于公用事业公司,电信公司等来说确实如此.

在这种情况下,您需要有一种方法为客户存储有效日期的多个地址,以便可以提前设置地址并自动切换到正确的位置.如果这是一个要求,那么(2)的变化是建模它的唯一合理方式,例如

Customer (id, ...)
Address (id, customer_id, address_type, valid_from, valid_to)

另一方面,如果您不需要满足此要求(并且您确定将来不会),则可能(1)管理起来更简单,因为维护数据完整性更容易,因为没有问题确保只存在一个相同类型的地址,并且连接变得更简单,因为它们只在一个字段上.

所以(1)或(2)都可以,这取决于你是否需要进行房屋搬迁,但我会避开(3),因为你正在重复表格中地址的定义,而你呢？如果更改地址的样子,则必须添加多个列.这可能稍微更好的性能,但要当你处理得当索引在关系数据库连接没有被获得了很多老实,很可能在某些情况下要慢一些,你不要需要地址因为客户的记录大小会更大.

Answer 3

我们正在推进这样的模型：

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％拥有用例。

地址表将遵循逐层表继承方案，以根据文化区分地址。因此，美国地址将包含州和邮政编码字段，而加拿大地址将具有省份和邮政编码。

我们使用一个单独的连接表来“给”一个人一个地址。当我们的经验会使沿途的事情变得复杂时，这使我们的其他实体-人员和地址-与其他实体没有联系。这也使将Address实体连接到许多其他类型的实体（人，组织等）以及具有与链接关联的不同上下文信息（例如本例中的activeDates）的过程变得更加简单。