正常化/验证数据库中的国际数据集？

Question

假设您正在处理您的正常联系人数据库（您知道...姓名，电话号码，地址，电子邮件等）。如果你在本地认识这件事，通常不是一个大问题需要处理，但是当我们看到国际化的时候它就是这样。

看着电话号码系统，你会认为它很简单，但实际上并非如此。在北美，我们通常有呼叫人的1-222-333-4444格式。 这当然被分解成您的国际拨号代码，地区代码，交换前缀和行号。问题：真实的电话号码是有限的，在潜在的1000中美国大约有220个地区代码，每个区号只有有限的交换次数，并且线路号仅限于该国家的特定用途（例如， 911的模式受到限制，只有10000个中的3/4被使用）。把这个交给英国，他们有自己的一系列线路规则，比如预留大部分0300-0399区块用于特定用途，以及其他限制。国际代码也是有限的。规范区号，交换和将数据验证检查放入电话号码变得复杂。我不会详细讨论我们何时进入不属于NPA scheme的地方，但我们只需确定我们不能真正相信北美模板，踢回来，并在一天内打电话。

我们如何规范这样的事情呢？我们如何验证数据？我们如何处理这些看似特殊的扩展代码或内部拨号指令？

International addresses没有太大的好处，不仅数据保留的差异，而且输出格式也不尽相同。在加拿大，我们如何处理国际邮政编码，格式为A1A1A1，美国有55555 [-4444]这样的系统？

我很想在我遇到这些情况时为每种情况编写类，并将它们作为XML/JSON /类似的方式存储在数据库中，但是如何关联字段并轻松搜索我的内容？我不想最终为每个国家创建数千张桌子。我想要一个可轻松扩展的解决方案，我可以规范我的地址并验证内容。这太难以问了吗？

Answer 1

处理这个问题的方式可以是：

采用三种观点的地址/电话号码/ POST代码等

1. 第一种观点是，地址（比如说）为多行的的文字。

2. 第二种观点是地址标记（更多见下文）。

3. 第三视图是为地址

所需要这种方法是用于验证的通用过程（类/触发）的其它部件的验证规则;用于打印目的的格式化例程;和一个规则库，以及一个管理员机制来更新验证规则。即使它不符合规则库中的任何规则，一个“catchall”规则表明这是一个有效的地址 - 它已经被手动验证过。

组件： 1地址由多行组成，每行都有一个关联的序列号和一些标记（通常为一个）。它也可以与地址线相关联，这是一组规则和它们经过验证的规则版本，但这是一种改进，取决于您的更新/插入/计算速率。

2地址标签就像城市;镇;门牌号码;并确定地址的不同行。有可能有一个没有任何标签的地址行，但在这种情况下，只有通用搜索（例如纽约）可能在整行行上。搜索“城市=纽约”）是不可能的。

3以域专用语言编写的规则。这可能是正则表达式;一种特定于你的语言;你的正常开发语言（尽管这可能是最不实用的方法，因为编程语言可能难以精确准确地表达我所谈论的规则。代表性规则的一个例子可能是（处理你对美国邮递区号） - 前五个字符必须是数字

前五个字符表示“区号”

邮政编码必须是地址的最后一行

的。规则将被分成组和集（例如美国地址）规则必须能够引用其他规则以及地址数据。

1. 您的验证例程需要占用地址的行并将规则应用于它（通常通过设置）。它将返回一个布尔型的有效或无效地址，以及可选的验证规则集。

2. 打印例程将再次将相应的规则集（可能与验证集不同）应用于地址数据以提供格式化的地址。

我希望其他组成部分是明显的整体方法。

这种做法是为了应对你的问题确定了这些问题：

1. 的电话代码分区。

2. 正在使用的可能区号的数量有限。

3. 为特定目的保留的电话号码块。

4. 数据标准化 - 数据被标准化。但是，除了数据仓库软件和包含大量实时传感器信息的数据库，通常不会使用这种标准化（反向索引）。在实施此解决方案时，您可能最终选择（可控地）重复数据。这不是解决方案的固有部分，但可能很方便。

5. 我强烈建议不要为每个变体添加类 - 这不是可缩放的，也不可维护的。

6. 搜索将在下面详细介绍。

7. 避免使用怪物表 - 规则库很可能是实际数据之外的数百到数千条规则的顺序。

8. 该解决方案是可扩展的 - 只需添加或修改规则即可。

并且还处理一些相关的问题。

1. 即使你可以将验证规则地址的国家形式，总会有例外的标准为特定国家。我自己的地址就是一个例子 - 我住在一条船上，并且需要我的地址中包含的其他信息，超出邮局标准地址。这种异常总是可能需要人工干预 - 因此人工干预可以接受这一规则。

2. 不同的国家有不同的地址排列顺序 - 例如中国的地址写为：国家;邮政编码;市;城区;街道名称;门牌号码;人名。

3. 接受您没有规则的地区的第一个地址，并且国家的规则与您所记录的地区不同。

4. 希望使用（例如办公室）地址与“他们的”地址不同的地址的人。

5. 具体的个人解决问题 - 有人希望隐藏他们离他们最近和最亲爱的信件。

6. 该解决方案可以扩展到像问题 - 例如指一个人。这可能涉及标题 - Dr，Rev等;多重连字符（ffoulkes-symthe）; （CPA，BSC等;以及家族资格（第三等）;以及取决于人文化的多种命名模式（来自印度次大陆的人们通常没有姓氏，并且每个人显然会有不同的姓氏。）

7. 变化解决规则（例如增加了一个新的发展的新邮编），可以方便，快捷地取得

问题仍然出现在：

1. 搜索会更复杂一些需要搜索地址的所有行和相关标记而不是特定地址字段

2. 建立此类规则库需要时间 - 尽管初始规则加载可以相当快地完成 - 示例存在于您的问题 - 只有在处理了多个异常和异常后，才会出现完整集合。

编辑：

我不知道的BigTable的时候，我写我的回应。在看了这篇文章之后，它似乎是一个非常相似的概念。至于在ACID开发中实现它，我认为这对联系人数据集和规则数据库是可能的。根据我的经验，我知道它很容易在这样的环境下轻松扩展到5 * 10^7套联系人详细信息（尽管有背景，不需要时间关键的联系方式验证）。

在考虑ACID/SQL的情况下，我对单词“view”的使用可能已经开始了一个向我不打算的方向发展的兔子。一个更合适的词可能是概述或展望（没有关系模型或DBMS运费的东西）。事实上，我将把我称之为视图的每一件事都视为候选人桌。

我为我的方法提供了一个草图，以帮助讨论。这个模式使用了一些M：N连接，这显然会在一个实现中被标准化为关联表。这是留给读者的练习:-)。我已将一些示例属性和数据放入一些表中。

在草图中，规则集的编辑;规则;并且与其他规则（管理应用程序）相关的规则显然可以通过Address User上的SQL Normal CRUD操作使用ACID属性完成;地址;和地址行可以同样以ACID/SQL方式完成，将地址行作为用户的输入。您可能希望对交易进行一些预处理，以从道路名称中分离（在我的示例中）房屋号码，并因此丢失“道路名称”规则。其他可能有用的预处理是大写的标准化 - 尽管这也可能是验证步骤的一部分。也可以简单地接受完整的“9 Richmond Road”作为输入，并将其标记为“需要验证”。在任何一种情况下，我都没有问题（我知道）关于创建此事务ACID的问题。

我不太清楚的是验证和后续标记如何结合到ACID/SQL事务中。看起来，要进行验证步骤ACID，可能需要根据规则集对测试应用进行排序（首先测试最常见的情况，并在验证成功时停止）。此外，为了使交易ACID只针对最常见的情况进行验证，可能有必要将其他标签标记为“需要验证”，然后将其作为后台任务完成。

验证的实际任务涉及检查整个规则库，按集合设置，直到找到一组验证所有输入行的规则。数据本身显然有潜在的指导原则 - 如果您记录了国家/地区，那么这两者都可以让您立即在国家/地区标记该行，并为必须测试的规则集提供过滤器。我很抱歉，但就目前来说，我可以采取这一方面。顺便提一句，这个草图模式只是部分走向了总归一化。如图所示，每个地址都有其自己的地址线序列，并且没有超出各行的数据标准化作为输入（加或减您选择执行的任何预处理）。有可能进一步采用这种方法 - 通过在地址和地址线M：N之间建立链接并确保地址线表的线域是其主键。

当谈到这个概念更详细的资源时，我有两个问题。

第一个（也是微不足道的）一个是，这个概念是我的原创工作，基于我作为方法顾问和IT策略顾问的20多年经验，对开发环境技术和开发方法有着特别的兴趣。我所有的工作生活都是在环境中度过的，环境中的联系方式一直是主要关注的问题（出于财务和法规/立法原因）。事实上，在我读完你的问题之前，我对你的问题的原始回答在我的脑海中完成了，尽管它让我花了四分之三个小时才完成。

更重要的原因是这个想法的一些来源是保密的或秘密的。在我的工作生涯中，我的部分工作涉及与技术发展保持同步，并预测十年后技术对业务的影响。这涉及访问研究实验室并与主要研究人员就各种主题进行讨论。虽然我不是，我自己是一流的研究人员，但我似乎很擅长综合其他人的研究成果。然而，在这样做的时候，我总是在商业机密和/或军事保密的条件下运营。我的答案都没有违反这些条件。由于这个原因，我只能给出如何得到信息的模糊指导。

我的来源是：

1. 被CĴ日期进行的，在IBM，探索正常化的进一步下游和关系模型（而不是作为在SQL中实现的关系模型）的研讨会。这包括探索第五（？）和第六（？）正常形式。

2. 一段时间内与Oracle技术人员进行的一系列讨论，讨论元数据;元元数据;和其他这样的概括。

3. 与英国军事研究机构的讨论。尽管这是几年前的事情，但我不确定在我们正在讨论的主题上是否发布过任何内容。

4. 在一家大型金融机构工作，其联系细节系统与我的建议非常相似，但是源于非关系型根源;在记忆，持久记忆和备份容量成为主要关注的时代，最初的技术动力是节省空间的。

编辑：

我完成上述编辑，闭嘴我的电脑，做了一些家务，上床睡觉，劳改了下来，闭上了眼睛，我有解决部分我无法完成之前的编辑。

虽然标记/验证大部分工作实际上是阅读和比较，但仍有更新需要完成。因此它是乐观锁定的主要候选者。在伪代码，这将是这样的：

Start read transaction 
    Read set of address lines where one or more lines are "Needs Validation" 
    Read all rule set names 
    Read all rule lines which belong to the first rule set 
    If read is not successful then abandon and start process again 
End read transaction 
Do while address not validated and not end of rule sets 
    If set of address lines validates against first rule set then 
    prepare transaction by allocating the tags to be applied to each line of the 
    address and temporarily recording the rule set that has validated the address 
    Start validation transaction 
     Read same set of address lines and rule set (all fields) 
     Is the address and the rule set identical to what was obtained in the read 
     transaction? 
     If identical then 
     create appropriate set of Tag Usage records 
     if successful then 
      commit validation transaction 
      end overall process 
     if not successful or 
     if not identical then 
      rollback validation Tag and Tag Usage 
      ** This is the point where there might be problems if the rule set has 
      changed since reading it. The ordering may have changed due to amendment 
      deletion or creation of rule sets. This is the reason for the read of all 
      the read set names initially. However if there is such a change one can 
      afford to fail to validate and move on, aiming to come back to this address 
      later. 
    End of validation transaction 
    Start read transaction 
     Read rule lines which belong to the next rule set 
    End read transaction 
End while loop 
If end of rule sets reached and address not validated 
    begin create Tag Usage transaction 
    create tag usage pointing to Tag "Manual Intervention needed" 
    end create Tag Usage transaction 

所有三种类型的交易（地址，地址线的更新，规则集，规则更新，以及标签，标签的使用更新）符合酸性条件。我坚信（但没有证明）这三种交易类型的任何交织，组合或交集都将满足ACID条件。

Answer 2

可能至少为already answered。您可以为邮政编码做类似的事情。

Answer 3

如果我会实现这个，我会保存电话号码，邮政编码等常规字符串。特别是数据应该以最终用户需要的格式存储。 （假设每个最终用户都有相同的需求）。有一个德国人的地址：“Roadname 123”，美国地址？ “123 Roadname”。对邮政编码也一样，将它们与城市名称结合使用。您可以将地址保存为address_line_1（街道名称，用户输入的国家特定顺序的门牌号码），address_line_2（邮政编码，城市名称...）。

如果您仍然需要在数据库中搜索特定的邮政编码，您可能会为此编写一个正则表达式或函数。考虑到城市名称，你可以将它们从address_line_2中清除出去，并且很有可能最终得到邮政编码。

我认为每个国家的写作验证必须是非常出色的工作，这就是200个国家......您如何确定您没有错过一些当地的会议？您可以编写一个函数eq，例如评估eq（“ABCDE-34”，“ABCDE.34”）== true。

尽管我没有真正看到写入客户端和服务器端验证的要点。即使客户端是Web浏览器，也可以通过AJAX使用服务器的验证。

最终它取决于您正在使用的DBMS（支持Java存储过程？），您的客户端语言......还有如何输入数据（在Web浏览器中输入的数据是否非常不准确？）以及你想要做什么。 （您是否打算给Skype提供数据库中的电话号码，或者将这些电话号码输入到手机中的人阅读）？您是否需要执行一些特定的加入操作？当然，这取决于你可以花多少工时来解决这个问题......