我正在尝试规范化地址。
下图显示了我认为的这个问题的相关表格。我想知道如何将ZipCodes集成到模型中。这将是国际地址,所以我知道Zip / PostalCode并没有在任何地方使用。我认为City :: ZipCode是1 :: 0-n(我读过其他人说这并非总是如此,但他们从未提供过证据)。如果他们是正确的,那么我想这将是一个多对多的关系。由于每个地址最多只能包含一个ZipCode,而ZipCode可以包含许多地址,因此我在如何规范化此模型时会丢失。
由于Address可能包含或不包含一个ZipCode,我需要避免在地址表中将其作为可空的FK。
编辑:只想强调所提供的实体和属性会从实际数据库中大幅缩减。它仅用作参考并解决我对将zipcodes包含在模型中的问题的关注。
答案 0 :(得分:6)
规范化您拥有的架构;添加一个表Address-ZipCode表,用外键地址ID和邮政编码;和主键地址ID - 与地址表中的相同。然后使用地址和新表之间的左连接包含Zip代码。只有当地址包含邮政编码时,才会填充新表。
但是,我建议如果您正在尝试容纳国际地址,那么您拥有的架构可能不够 - 您需要多个地址线和更多级别的类别,而不是图中所示。遗漏的类别包括国家,次区域,城镇和其他可能的其他类别。
我的回答here(非常长)显示了全面处理国际地址(和其他事情)所需的内容。除非您在多个国家/地区的每个国家/地区处理数百万个地址,否则这将是一次大规模的过度杀伤。
答案 1 :(得分:2)
我最终看起来有点像这样:
tblState:
StateID
StateCode (AL, AK, AR . . . etc)
StateName (Alabama, Alaska, Arkansas, . . . etc)
tblCounty
CountyID
HUDRegionID FK to tblHUDRegion
StateID FK to tbleState
CountyName (Pierce County, WA; Lane County, OR)
NOTE: I recognize I could normalize even further and create a table of count names, many-to-many related to States ON stateID, but there's a limit, man!)
tblCity
CityID
CountyID
CityName
tblZIPCOde
ZIPCodeID
CityID
tblHUDRegion
HUDRegionID
HUDRegionCode
HUDRegionName
就我而言,HUD地区是在县一级定义的(一个HUD地区包括一个或多个县(或某些情况下为“县城”)。每个HUD地区实际上都有一个唯一标识符定义为HUD(HUD) CBSA_Sub),我用它作为“HUD-region_code”。另外需要注意的是HUD区域可以包括一个或多个状态的县。因此,HUD区域标识符与县相关,但只是间接地与州相关,通过每个例如,HUD“波特兰/温哥华/比弗顿”HUD MSA包括俄勒冈州和华盛顿州的县(和城市)。
在您的情况下,您需要再定义一个顶层tblCountry。此外,您可能需要调整“县”和“州”的概念以适应其他国家(“省”以及它们用于大于城市但小于州的细分。“地区”可能适用于此情况同样 - 我相信很多欧洲的coutnries都使用“地区”)。
一个国家/地区有一个或多个国家(或等同)。州有一个或多个县(或等同)。一个县有一个或多个城市。城市往往至少有一个邮政编码。
在我的情况下,像HUD地区这样的区域往往被定义为这些级别之一的聚合。
在许多情况下,在这个HUD驱动的模型之外我必须开发(通常需要确定哪个HUD MSA通过ZIP或县工作。在所有情况下,它是不安全的假设HUD区域包含在特定状态中。
另外需要注意的是,USPS会定期更改某些区域的邮政编码。
答案 2 :(得分:2)
对于需要准确,定期格式化地址的大多数实体来说,规范化或标准化地址是一个巨大的问题。 (我在地址验证行业工作 - SmartyStreets - 所以我已经处理了很多这样的事情。)由于不同的传递端点的复杂性,地址变化,地址组件的更新以及许多其他事情,最好是招募一个认证服务来为你照顾。
假设您正在使用美国地址,您可以轻松地连接到API或列表处理服务,以获取所需的数据。例如,如果您遇到与NULLable ZipCode FK有关的问题,那么您也可以将邮政编码附加到每个地址(如果找不到,那么为什么要保留它,因为它仍然是一个糟糕的地址)。 / p>
一个此类服务是LiveAddress,它处理API请求,或者您可以使用我们的CASS-Certified Scrubbing处理现有的地址列表/表。无论哪种方式,我都很乐意亲自帮助您创建一个有效的解决方案......
答案 3 :(得分:1)
根据您所在的国家/地区的邮政编码规则可能会非常冒险。您可以非常安全地假设邮政编码有一个正式的城市名称,但美国和加拿大都允许使用邮政编码的替代城市名称。我知道这是因为我为北美开发了邮政地址验证软件。非官方名称通常由邮政当局承认,您通常必须允许其使用。
因此,如果您希望能够使用非官方名称,则需要在城市和邮政编码之间使用m:n。我会问你为什么要在任何情况下都想要邮政编码的代码表。地址存储最好将它们视为独立属性,而不是试图将它们标准化。
如果您认为您可以使用数据库中的某些数据从邮政编码转发到城市名称或从城市名称转发到邮政编码,那么您就会让自己失望!美国邮政和加拿大邮政认可的软件解决方案可用于进行地址验证,如果您花费任何时间进行实际调查,您会发现地址验证的问题域很多比您想象的要复杂得多是。如果地址准确性对您的应用程序很重要(并且在大多数情况下应该是这样),那么请购买第三方工具来进行地址验证,并将您的地址存储在一个表中,其中包含尽可能多的列。
答案 4 :(得分:0)
邮政编码has_many地址/地址belongs_to zip_code。你需要正常化吗?大多数应用程序最好只在地址表中有一个zip_code列。维护国际地址的所有邮政编码是一场艰苦的战斗。
此外,您正在复制地址和城市中的region_id。您可能需要解释您的应用中的哪个区域,但这看起来只需要在城市中。
答案 5 :(得分:0)
全球190个国家中有119个使用邮政编码。不使用它们的着名国家包括爱尔兰和巴拿马。[1]
除了支持这一事实外,它还是一个非常讨厌的系统,坚持使用邮政编码。它还应该允许邮政编码未知。
在美国,每个“城市”至少有一个邮政编码,因此这种关系是正确的。我知道这是从开发邮政编码数据库大约一年。