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

我会用 Address 表,正如您所建议的,我将根据 xAL .

我也一直在思考这个问题。到目前为止,我有一些松散的想法,我想知道其他人是怎么想的。

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
}

这很容易映射到一个数据库表中,只允许在大多数列上使用空值。亚马逊和许多组织似乎就是这样存储地址数据的。所以剩下的问题是,我应该如何在一个容易被程序员和任何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属性并使用 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)
}

设置字段时, 地址 对象将在其内部调用适当的方法 地址策略 对象。

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

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

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

如果我们想 地址 对象本身在创建后的行为就像一个不变的对象。(我可能会尝试这样做,因为 地址 对象实际上更像一个数据结构,并且可能永远不会有任何与自身关联的真正行为。)

这有道理吗?我是否偏离了OOP路径太远?对我来说,这代表了一个相当明智的折衷方案,即抽象到几乎不可能实现(xal),而严格地说,是我们的偏见。

两年后更新: 我最终得到了一个类似的系统,并在 my defunct blog .

我觉得这个解决方案是传统数据和关系数据存储之间的正确平衡,至少对于电子商务界是这样。

在英国有一种叫 PAF from Royal Mail

这为每个地址提供了一个唯一的密钥——不过,还有一些环可以跳过。

如果你想要一致性,我基本上会看到两种选择:

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

广告1。我与SAS系统合作,SAS研究所提供了一个数据清理工具——这基本上对您的数据进行了一些检查和验证,并建议将“Abram Lincoln Road”和“Abraham Lincoln Road”合并到同一条街上。我还认为它利用了国家数据库,其中包含城市邮政编码匹配等。

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

请注意,这些选项并不排除彼此,您可以同时使用这两种方法。

关于地址构造的权威通常是邮政服务,因此首先,我将检查邮政服务在您经营的主要市场中使用的数据元素。

有关国际邮政地址格式的非常具体和详细的信息,请参阅世界邮政联盟的网站: http://www.upu.int/post_code/en/postal_addressing_systems_member_countries.shtml

“XAL是最接近出现的全球标准的东西。不过,这似乎是一种过度杀伤力,我不确定是否有很多人希望在他们的数据库中实现它……”

这不是一个相关的论点。如果系统需要“全面和一致”(即全球范围),那么实现地址不是一项简单的任务。执行这样的标准确实很费时,但要满足规定的要求仍然是强制性的。

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

我之前问过类似的问题: Dynamic contact information data/design pattern: Is this in any way feasible? .

简短的回答是:在数据库中存储adderres或任何类型的联系信息都很复杂。上面的可扩展地址语言(Xal)链接包含一些有趣的信息,这些信息最接近我所遇到的标准/最佳实践…

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