数据库中一致和全面地址存储的最佳实践[关闭]

Question

是否有任何最佳实践（甚至标准）以一致和全面的方式在数据库中存储地址？

更具体地说，我认为在这个阶段有两种地址存储的情况：

• 您只需要将地址与人，建筑物或任何项目（最常见的情况）相关联。 然后一个带有文本列（address1，address2，zip，city）的平面表就足够了。 这不是我感兴趣的情况。
• 您想要对您的地址运行统计信息：特定街道或城市中的项目数量......然后您希望避免任何类型的拼写错误，并确保一致性。 我的问题是关于这个特定情况下的最佳实践：建立一致地址数据库的最佳方法是什么？

特定国家的设计/解决方案将是一个很好的开端。

答案 ：这个问题似乎还没有完美答案，但是：

• 正如 汉克所建议的 那样 ， xAL是最接近出现的全球标准的东西。 虽然看起来有点矫枉过正，但我​​不确定很多人会想要在他们的数据库中实现它......
• 为了开始自己的设计（针对特定国家）， Dave与万国邮政联盟 （UPU）网站的链接是一个非常好的起点。
• 至于法国，地址有一个标准（非官方，但事实上的标准），其中有一个可爱的名字AFNOR XP Z10-011 （仅限法语），并且必须付费。 法国的UPU描述基于这一规范。
• 我碰巧找到了瑞典的等效标准： SS 613401 。
• 在欧洲层面，已经做出了一些努力，产生了标准EN 14142-1。 它可以通过CEN国家成员获得。

Answer 1

我自己也在考虑这个问题。 到目前为止，这是我的松散想法，我想知道其他人的想法。

xAL（及其姐妹，其中包括个人姓名，XNAL）被谷歌和雅虎的地理编码服务使用，这给了它一些重量。 但是由于可以用许多不同的方式在xAL中描述相同的地址 - 某些地址比其他地方更具体 - 然后我不知道xAL本身是如何可接受的数据存储格式。 但是，可以使用其中的一些字段名称，但实际上，我公司运送到的16个国家/地区中唯一可以使用的基本格式如下：

enum address-fields 
{
    name,
    company-name,
    street-lines[], // up to 4 free-type street lines
    county/sublocality,
    city/town/district,
    state/province/region/territory,
    postal-code,
    country
}

这很容易映射到单个数据库表，只允许在大多数列上使用NULL。 这似乎是亚马逊和许多组织实际存储地址数据的方式。 所以剩下的问题是我应该如何在一个易于被程序员和任何GUI代码使用的对象模型中进行建模。 我们是否有一个基Address类型，其中包含每种类型地址的子类，例如AmericanAddress ， CanadianAddress ， GermanAddress等等？ 这些地址类型中的每一种都知道如何格式化自己，并且可选地会对字段的验证有所了解。

他们还可以返回关于每个字段的某种类型的元数据，例如以下伪代码数据结构：

structure address-field-metadata 
{
    field-number,     // corresponds to the enumeration above
    field-index,      // the order in which the field is usually displayed
    field-name,       // a "localized" name; US == "State", CA == "Province", etc
    is-applicable,    // whether or not the field is even looked at / valid
    is-required,      // whether or not the field is required
    validation-regex, // an optional regex to apply against the field
    allowed-values[]  // an optional array of specific values the field can be set to
}

实际上，我们可以采用稍微不那么面向对象的方法，使用一个避免.NET属性的Address对象并使用AddressStrategy来确定格式和验证规则，而不是为每个国家/地区设置单独的地址对象：

object address
{
    set-field(field-number, field-value),
    address-strategy
}

object address-strategy
{
    validate-field(field-number, field-value),
    cleanse-address(address),
    format-address(address, formatting-options)
}

设置字段时，该Address对象将在其内部AddressStrategy对象上调用适当的方法。

使用SetField()方法方法而不是使用getter和setter属性的原因是，代码更容易以通用方式实际设置这些字段，而无需使用反射或switch语句。

你可以想象这个过程是这样的：

1. GUI代码调用工厂方法或类似方法来创建基于国家/地区的地址。 （然后，国家下拉菜单是客户选择的第一件事，或者根据文化信息或IP地址为他们预先选择好的猜测。）
2. GUI调用address.GetMetadata()或类似方法，并接收如上所述的AddressFieldMetadata结构的列表。 它可以使用此元数据来确定要显示的字段（忽略那些is-applicable设置为false字段），标记这些字段的内容（使用field-name成员），按特定顺序显示这些字段，以及执行粗略，演示对该数据进行级别验证（使用is-required ， validation-regex和allowed-values成员）。
3. GUI使用field-number （对应于上面的枚举）及其给定值来调用address.SetField()方法。 然后， Address对象或其策略可以对这些字段执行某些高级地址验证，调用地址清除程序等。

如果我们想让Address对象本身在创建后表现得像一个不可变对象，那么上面可能会略有不同。 （我可能会尝试这样做，因为Address对象实际上更像是一个数据结构，并且可能永远不会有任何与自身相关的真实行为。）

这有什么意义吗？ 我是否偏离了OOP路径太远了？ 对我来说，这代表了一种非常合理的妥协，它是如此抽象，以至于实现几乎不可能（xAL）与严格偏向美国。

---

2年后更新：我最终得到了一个与此类似的系统，并在我已经不存在的博客上写了这篇文章 。

我觉得这个解决方案是遗留数据和关系数据存储之间的正确平衡，至少对于电子商务世界而言。

Answer 2

正如你所建议的那样，我会使用一个Address表，我将它基于xAL跟踪的数据。

Answer 3

在英国，皇家邮政有一种名为PAF的产品

这为每个地址提供了一个唯一的密钥 - 尽管如此，还是有可以跳过的箍。

Answer 4

如果你想要一致性我基本上看到2个选择：

1. 数据清理
2. 基本数据表查找

广告1.我使用SAS系统，SAS Institute提供数据清理工具 - 这基本上对您的数据执行一些检查和验证，并建议将“Abram Lincoln Road”和“Abraham Lincoln Road”合并到同一个街。 我还认为它借鉴了包含城市邮政代码匹配等的国家数据库。

广告2.您构建了一个多选列表（即基本数据），添加新条目的人员从基本数据中的现有条目中进行选择。 在事实表中，您将键存储到街道名称而不是街道名称本身。 如果您检测到拼写错误，则只需在基本数据中进行更正，并通过密钥关系对所有实例进行更正。

请注意，这些选项不会相互排除，您可以同时使用这两种方法。

Answer 5

关于如何构建地址的权限通常是邮政服务，因此首先我将检查邮政服务为您运营的主要市场使用的数据元素。

有关国际邮政地址格式的详细信息，请参阅万国邮政联盟网站： http ： //www.upu.int/post_code/en/postal_addressing_systems_member_countries.shtml

Answer 6

“xAl是最接近弹出的全球标准的东西。虽然看起来有点矫枉过正，但我​​不确定很多人会想要在他们的数据库中实现它......”

这不是一个相关的论点。 如果系统需要“全面和一致”（即在全球范围内），那么实现地址并非易事。 实施这样的标准确实很耗时，但是为了满足规定的要求，仍然是强制性的。

Answer 7

规范化您的数据库架构，您将拥有完美的结构以实现正确的一致性。 这就是原因： http ： //weblogs.sqlteam.com/mladenp/archive/2008/09/17/Normalization-for-databases-is-like-Dependency-Injection-for-code.aspx

Answer 8

我之前问过类似的东西： 动态联系信息数据/设计模式：这是否可行？ 。

简短的回答：在数据库中存储adderres或任何类型的联系信息都很复杂。 上面的可扩展地址语言（xAL）链接有一些有趣的信息，这些信息最接近我所遇到的标准/最佳实践......

Answer 9

在美国，我建议选择一个国家地址变更供应商，并在他们返回后对数据库进行建模。