每个人Customer都有一个物理地址和一个可选的邮寄地址。你对此模型的首选方式是什么?
选项1 Customer有外键Address
客户(id,phys_address_id,mail_address_id)
地址(身份证,街道,城市等)
选项2 Customer具有一对多的关系Address,其中包含一个描述地址类型的字段
客户ID)
地址(id,customer_id,address_type,街道,城市等)
选项3.地址信息被解除标准化并存储 Customer
客户(id,phys_street,phys_city等mail_street,mail_city等)
我最重要的目标之一是简化对象关系映射,所以我倾向于第一种方法。你怎么看?
发布于 2018-04-24 13:40:45
我倾向于第一种方法来实现常态化的所有常见原因。这种方法还可以更轻松地在邮件详细信息上执行数据清理。
如果可能会允许多个地址(邮件,住宅等)或希望能够使用生效日期,请考虑此方法
客户(id,phys_address_id)
Cust_address_type(cust_id,mail_address_id,address_type,start_date,end_date)
地址(身份证,街道,城市等)
发布于 2018-04-24 13:46:29
可能需要考虑的一个重要事实(取决于您的问题域)是人们更改地址,并可能希望在地址更改之前通知您; 这对公用事业公司,电信公司等来说肯定是正确的。
在这种情况下,需要有一种方法可以为客户存储具有有效日期的多个地址,以便可以提前设置地址并自动切换到正确的地点。如果这是一个要求,那么对(2)的变化是模型化的唯一明智的方式,例如
Customer (id, ...)
Address (id, customer_id, address_type, valid_from, valid_to)
另一方面,如果你不需要迎合这一点(而且你确信你将来不会),那么可能(1)更容易管理,因为保持数据完整性要容易得多,因为没有问题确保只有一个相同类型的地址存在,并且连接变得更简单,因为它们只在一个字段上。
所以无论是(1)还是(2)都很好,这取决于你是否需要搬家,但是我会避开(3),因为你会重复表格中地址的定义,如果你改变一个地址的样子,你必须添加多个列。这可能稍微更好的性能,但要当你处理得当索引在关系数据库连接没有被获得了很多老实,很可能在某些情况下要慢一些,你不要需要地址因为客户的记录尺寸会更大。
https://stackoverflow.com/questions/-100008243
复制相似问题