存储不同实体的“地址”的最佳架构是什么?

时间:2009-07-27 02:02:03

标签: sql database database-design schema street-address

假设我们正在制作一个系统,我们必须存储建筑物的附加物, 人,汽车等

地址'格式'应该是这样的:

State  (From a State list)
County (From a County List)
Street (free text, like '5th Avenue')
Number (free text, like 'Chrysler Building, Floor 10, Office No. 10')

(是的,我不住在美国)

存储该信息的最佳方式是什么:

  • 我应该有Person_AddressCar_Address,......
  • 或者地址信息应该在每个实体的列中,
  • 我们可以只有一个地址表并尝试将每一行链接到另一个实体吗?

还是有另一种“更好”的方式来处理这种情况吗? 你会怎么做?

3 个答案:

答案 0 :(得分:1)

我见过地址存储在地址表中然后存在多对多链接表的场景,这些链接表存储了People的地址链接 - 每个都有一个单独的表,以便可以强制执行外键。有时,链接表存储有关关系的信息,如主要,送货等等。

我也看到了地址存储在客户行中的位置。这样可以有效地为收单方,收货方等提供地址数组,这样就可以了。处理完这两个后,我认为我更喜欢在他们自己的实体中使用它们,它允许您非常容易地保留旧的非活动地址的历史记录。

我们对电话号码使用了相同的技术,人们需要存储不同数量的电话号码。

答案 1 :(得分:1)

我强烈建议阅读David C. Hay撰写的“数据模型模式 - 思想公约”。作者深入讨论了这个问题。
您在设计中拥有的是两个广泛的实体。

  1. 地理位置地址
  2. 居住/属于该地址的人/物件
  3. 一般情况下,将地址与一个或多个人的详细信息组合在同一个表中并不是一个好习惯

    Person(personID, name, gender, addressline1, addressline2)
    

    您的设计中可以包含以下实体

    Address(number, street, countyID,stateID)
    Party(PartyID, Type)
    Person(PersonID, name, dob, gender,...,primaryPartyID)
    Car(carID, make, model, ...,primaryPartyID)
    

    派对是人/车与地址之间的链接。 personPartyID in person和Car表是聚会表的外键。这样,您就可以在汽车和人之间共享和寻址。如果您想为每个人存储多个地址,您可以在人与方之间添加单独的m:n表。 Party的类型属性可以采用以下值:'人','车辆'等......

答案 2 :(得分:0)

我想说一个AddressType字段是从下拉列表中查找