街道地址的最佳标准化是什么?

时间:2011-11-17 12:19:45

标签: mysql normalization

今天我有一张包含以下内容的表:

Table a
--------
name
description
street1
street2
zipcode
city
fk_countryID

我正在讨论在最快搜索方面规范化的最佳方法是什么。例如。查找按城市或邮政编码过滤的所有行。建议的新结构是:

Table A
--------
name
description
fk_streetID
streetNumber
zipcode
fk_countryID

Table Street
--------
id
street1
street2
fk_cityID

Table City
----------
id
name

Table Country
-------------
id
name

关于街道名称只有一个字段而不是两个字段 我的论点是,有两个领域被认为是支持国际地址的正常现象。

专业论证是,它将继续在搜索和可能的重复方面的性能成本。

我想知道去这里的最佳方式是什么。

更新

我的目标是拥有15.000个品牌与50.000个商店相关联,其中1.000个用户每天将通过网络和iPhone进行多次搜索。此外,我将有3.方从数据库中为其网站提取数据。

该网站尚未启动,因此我们不知道工作量。当我们开始时,我们将只有大约1000个品牌与大约4000家商店相关联。

4 个答案:

答案 0 :(得分:2)

我的标准建议(来自多年的数据仓库/ BI经验)在这里是:
始终存储最低级别的细分,即多个字段选项。

除此之外,根据您的需要,您可以添加索引甚至是另外两个字段连接的复合字段 - 尽管确保使用触发器而不是手动维护,否则您将遇到数据同步和质量问题。
部分正确答案将取决于您的实际使用情况。您是否可以预期需要以标准(2行)格式发送地址或与其他实体交换?或者这是一个非常纯粹的“只读”数据库,它只是为查询设置而不是用于更多标准地址需求,例如邮件。

如果您在查询性能方面遇到问题,可以在一天结束时添加其他结构,例如复合字段,索引甚至其他具有相同数据的表格。如果性能较慢,还可以在服务器级别进行缓存选项。如果构建一个复杂或流量密集的站点,您最终可能会得到一个产品来提供帮助,例如在Ruby编程世界中人们使用thinking sphinx如果查询性能仍然存在问题并且您的数据正在增长,那么您可能会最终需要考虑像MongoDB这样的非SQL解决方案。

我还坚持的最后一个原则:考虑人们如果在这个系统中发生更新数据。当人们最初输入数据然后去编辑那些信息时,他们希望信息“相同”,因此在内部进行的实际改变用户输入形式或内容的任何操作都将成为尝试允许它们时的一个主要问题。做一个简单的编辑。我已经看到了以这种方式编码和解码数据的极其复杂的算法,并且它们经常出现问题。

答案 1 :(得分:1)

请注意,高规范化意味着更多联接,因此在每种情况下都不会产生更快的搜索速度。

答案 2 :(得分:1)

我认为最重要的例子是要走的路,也许是第三个自由形式的领域:

name
description
street1
street2
street3
zipcode
city
fk_countryID

你唯一可以在国际地址中途理想化的是邮政编码(虽然需要是一个自由形式的领域)和城市。街道地址变化太大了。

答案 3 :(得分:0)

正如其他人所提到的,当数据在一个表中,但各个部分位于不同的列(如第一个示例)时,地址规范化(或“标准化”)最有效。我在地址验证领域工作(在SmartyStreets),你会发现标准化地址是一项非常复杂的任务。这里有关于此任务的更多文档:https://www.smartystreets.com/Features/Standardization/

随着您将要处理的请求量,我强烈建议您在部署之前确保地址正确。处理您的地址列表并删除重复项,标准化格式等.CASS认证的供应商(如SmartyStreets,尽管还有其他供应商)将提供此类服务。