规范化/验证数据库中的国际数据集？

Question

假设您正在处理您的正常联系人数据库(您知道...姓名,电话号码,地址,电子邮件等...).如果你在当地对此表示不满,那么处理这个问题通常不是一个大问题,但是当我们看到国际集时,它就是.

看着电话号码系统,你会认为这很简单,但事实并非如此.在北美,我们通常有1-222-333-4444格式用于呼叫人.这当然分为您的国际拨号代码,区号,交换前缀和行号.问题:实际电话号码是有限的,美国大约有220个区号在潜在的1000个区域内,每个区号只有有限数量的交换机,并且线路号码仅限于该国家/地区的特定用途(例如, 911的模式受到限制,只有10,000个中的约3/4在使用中.把这个带到英国,他们有自己的行号规则,例如保留0300-0399块的大部分特定用途,以及其他限制.国际代码也是有限的.规范区号,交换,并将数据验证检查放到电话号码上变得复杂了.我不会详细说明我们何时进入不属于该地区的地方NPA计划,但我们只是确定我们不能真正信任北美模板,踢回去,并称之为一天.

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

国际地址不是更好,不仅保留数据之间的差异,而且输出格式也不尽相同.我们如何处理国际邮政编码,加拿大的格式是A1A1A1,而美国的系统如55555 [-4444]？

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

Answer 1

解决此问题的方法可能是:

采用地址/电话号码/邮政编码等三种视图

1. 第一个视图是地址(例如)作为多行文本.

2. 第二种观点是地址标签(下面有更多内容).

3. 第三种观点是地址验证规则

此方法所需的其他组件是用于验证的通用过程(类/触发器); 用于打印目的的格式化程序; 和规则库,以及管理员机制来更新验证规则.一个"catchall"规则,它说这是一个有效的地址 - 它已经过手动验证 - 即使它不符合规则库的任何规则.

组件:1地址由多行组成,每行包含一个相关的序列号和多个标签(通常为一个).也可以与地址行,规则集以及验证它们的规则版本相关联,但这是一个取决于更新/插入/计算速率的细化.

2地址标签就像城市; 镇; 门牌号码; 并确定地址的不同行.可以有一个没有任何标签的地址线,但在这种情况下,只有通用搜索(例如纽约)才能在整套线上进行.搜索"City = New York")是不可能的.

3以域特定语言编写的规则.这可能是正则表达; 一种特定于您的语言; 你的正常开发语言(尽管这可能是最不实用的方法,因为编程语言很难简明扼要地准确地表示我所讨论的那种规则.代表性规则的一个例子可能是(处理你的描述)美国邮政编码) - 前五个字符必须是数字.

前五个字符代表"区号".

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

规则将分为组和集(例如美国地址)规则必须能够引用其他规则以及地址数据.

1. 您的验证例程需要获取地址行并将规则应用于它(通常通过设置).它将返回一个布尔值 - 有效或无效的地址,并可选择返回它验证的规则集.

2. 打印例程将再次将适当的规则集(可能与您的验证集不同)应用于地址数据,以提供格式化的地址.

我希望其他组件从整体方法中显而易见.

此方法旨在处理您的问题中确定的这些问题:

1. 电话代码分区.

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

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

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

5. 我强烈建议不要为每个变体添加类 - 这不是可扩展的,也不可维护的.

6. 搜索详情如下.

7. 避免使用怪物表 - 规则库可能是实际数据的数百到数千的规则.

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

并处理一些相关问题.

1. 即使您可以将验证规则应用于国家地址格式,对于特定国家/地区的标准也始终存在例外情况.我自己的地址就是一个例子 - 我住在船上,需要在我的地址中包含的其他信息,超出邮局标准地址.这种异常总是可能需要人工干预 - 因此通过人工干预接受的规则.

2. 不同的国家对地址有不同的排序 - 例如中国的地址是:国家; 邮政编码; 市; 城区; 街道名称; 门牌号码; 人名.

3. 从您没有规则的区域接受第一个地址,并且该国家/地区的规则与您记录的任何地区不同.

4. 人们想要使用(例如办公室)地址与"他们的"地址不同.

5. 具体的个人解决问题 - 有人希望隐藏他们与最亲近的人之间的通信.

6. 解决方案可以扩展到类似的问题 - 例如,指一个人.这可能涉及标题 - Dr,Rev等; 乘以连字符的名字(ffoulkes-symthe); 资格(注册会计师,理学士等;以及家庭资格(第三等);以及根据人文化的多种命名模式(来自印度次大陆的人通常没有姓氏,每个人显然都有不同的姓氏).

7. 可以轻松快速地更改寻址规则(例如,为新开发添加新的邮政编码).

仍然出现的问题是:

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

2. 构建这种规则库需要花费一些时间 - 虽然初始规则加载可以相当快速地完成 - 您的问题中会出现示例 - 只有完整集合才会在处理多个异常和异常之后出现.

编辑:

当我写回复时,我不知道BigTable.很快就看到了它,它似乎是一个非常相似的概念.至于在ACID开发中实现它,我认为这对于联系人数据集和规则数据库是可能的.根据我的经验,我知道在这样的环境中它很容易扩展到5*10 ^ 7组联系人详细信息(尽管有背景,非时间关键的联系方式验证).

在考虑ACID/SQL案例时,我对"视图"这个词的使用可能已经开始了一个我不想要的方向的野兔.一个更合适的词可能是概述或前景(没有关系模型或附加DBMS运费的东西).事实上,我会将每个我称之为视图的东西视为候选表.

我为我的方法制定了一个模式草图,以协助讨论.此模式使用一些M:N连接,这显然会在实现中作为关联表进行规范化.这留给读者练习:-).我在一些表中添加了一些示例属性和数据.

在草图中,编辑规则集; 规则; 和其他规则(管理应用程序)相关的规则显然可以通过SQL Normal CRUD操作在地址用户上使用ACID属性来完成; 地址; 和地址线同样可以以ACID/SQL方式完成,将地址线作为用户的输入.您可能希望对交易进行一些预处理,以便(在我的示例中)将门牌号与道路名称分开,从而失去"道路名称"规则.其他可能有用的预处理是资本化的标准化 - 尽管这也可能是验证步骤的一部分.也可以简单地接受完整的"9 Richmond Road"作为输入,并将其标记为"Needs Validation".

我不太清楚的是如何将验证和后续标记合并到ACID/SQL事务中.似乎要进行验证步骤ACID,可能需要针对规则集排序测试的应用程序(首先测试最常见的情况,并在验证成功时停止).此外,为了使事务ACID,可能有必要仅针对您最常见的情况进行验证,将其他情况标记为"需要验证",然后将其作为后台任务完成.

验证的实际任务包括检查由set设置的整个规则库,直到找到一组验证所有输入行的规则.数据本身显然有潜在的指导方针 - 如果您已经记录了国家/地区,那么这两者都可以让您直接在国家/地区标记该行,并为您必须测试的规则集提供过滤器.我很抱歉,到目前为止,这是我可以采取的这方面.

顺便说一下,这个草图模式只是朝着完全标准化的方向发展.如图所示,每个地址都有自己的地址行序列,并且没有将各个行之外的数据标准化为输入(加上或减去您选择执行的任何预处理).通过在地址和地址线M:N之间建立链接并确保地址线表的线路字段是其主键,可以进一步采用这种方法.

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

第一个(也是微不足道的)是这个概念是我的原创作品,基于我作为方法顾问和IT战略顾问二十多年的经验,他对开发环境技术和开发方法特别感兴趣.我的所有工作生涯都花在了联系方式主要受到关注的环境中(出于财务和监管/立法原因).事实上,在我读完你的问题之前,我对你的问题的原始回答是完整的,尽管它确实花了我大约四分之三个小时来打字.

更重要的原因是这个想法的一些来源是保密的或秘密的.在我的工作生涯中,我的部分工作包括跟上技术发展的最新动态,并在十年内预测技术对业务的影响.这包括访问研究实验室,并与主要研究人员讨论各种主题.虽然我不是,我自己,一流的研究员,但我似乎非常擅长综合其他人的研究工作.然而,在这样做时,我总是在商业机密和/或军事保密的条件下运作.我的答案都没有违反这些条件.因此,我只能就如何得出信息给出含糊的指导.

我的消息来源是:

1. 由CJ Date在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条件.我坚信(但尚未证明)这三种交易的任何交错,组合或交叉集合也将满足ACID条件.