数据库中一致且全面的地址存储的最佳实践

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

5 年前已关闭。

Answer 1

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

Answer 2

我之前问过一些非常类似的问题：动态联系信息数据/设计模式：是这有什么可行的办法吗？。

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

Answer 3

“xAl 是最接近出现的全球标准的东西。不过，这似乎有点矫枉过正，我不确定很多人会想在他们的数据库中实现它......”

这不是一个相关的论点。 如果系统需要“全面且一致”（即全球范围内），那么实现地址并不是一项简单的任务。 实施这样的标准确实很耗时，但要满足指定的要求仍然是强制性的。

Answer 4

在英国，有一款名为 Royal Mail 的 PAF

这为每个地址提供了一个唯一的密钥 - 不过，有一些障碍需要跳过。

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

地址构建的权威机构通常是邮政服务，因此首先我将检查邮政服务针对您所在的主要市场所使用的数据元素。

请参阅万国邮政联盟的网站以获取非常具体和详细的​​信息关于国际邮政地址格式：http://www.upu.int/post_code/en/ postal_addressing_systems_member_countries.shtml

Answer 8

正如您所建议的，我将使用 Address 表，并且将其基于 xAL。

Answer 9

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

xAL（及其包含个人姓名的姐妹 XNAL）被 Google 和 Yahoo 的地理编码服务使用，从而赋予它一定的权重。 但由于相同的地址可以在 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
}

事实上，我们可以采用稍微不那么面向对象的方法，即使用 Address 对象避开 .NET 属性并使用 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 和允许值 成员）。
3. GUI 使用field-number（对应于上面的枚举）及其给定值调用address.SetField() 方法。 然后，Address 对象或其策略可以对这些字段执行一些高级地址验证，调用地址清理器等。

如果我们想要创建 Address，则上述内容可能会略有不同code> 对象一旦创建，其行为就像一个不可变的对象。 （我可能会尝试这样做，因为 Address 对象实际上更像是一个数据结构，并且可能永远不会有任何与其自身相关的真实行为。）

这一切有意义吗？ 我是否偏离 OOP 道路太远了？ 对我来说，这代表了一种非常明智的妥协，既抽象得几乎不可能实现（xAL），又与严格偏向美国之间做出妥协。

---

2年后更新：我最终得到了一个与此类似的系统，并在 我已不复存在的博客。

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