看电话号码系统,你会觉得很简单,但实际上并不是这样.在北美,我们一般有1-222-333-4444格式叫人.
这当然是被划分为您的国际拨号代码,区号,交换前缀和行号.问题：实际电话号码有限,美国有大约220个地区代码,潜在的1000个,每个区号只有有限的交换次数,而行号只限于该国的具体使用(例如,911的模式受到限制,只有10,000个用户中的大约3/4使用).把它交给英国,他们有自己的行号规则,比如把大部分的0300-0399块保留到特定的用途,以及其他限制.国际法规也受到限制.规范区域代码,交换和投放
对电话号码的数据验证检查变得复杂.我不会详细介绍当我们进入不属于NPA scheme的地方的时候,但是我们只能确定我们不能真正相信北美的模板,反过来称之为一天.
我们如何规范这样的事情？我们如何验证数据？我们如何处理这些看似特别的扩展代码或内部拨号的说明？
International addresses不是好多了,差异不仅仅是数据保留,而且输出格式都不一样.我们如何处理国际邮政编码,加拿大的格式是A1A1A1,美国有55555 [-4444]等系统？
我遇到这样的情况时,只需要为每一种情况编写课程,将它们存储在XML / JSON /类似的数据库中,然后如何关联字段并轻松搜索我的内容？我不想最终为每个国家创建一个桌子最多的数千张桌子.我想要一个容易扩展的解决方案,我可以对我的地址进行规范化并验证内容.这个问题太多了吗？
解决方法
采用地址/电话号码/邮政编码等三种方式.
>第一个视图是地址(说)作为多行文本.
>第二个视图是地址标签(在下面的更多内容).
>第三个视图是地址的验证规则
此方法所需的其他组件是用于验证的通用过程(类/触发器)用于打印目的的格式化例程以及一个规则库,以及更新验证规则的管理员机制.一个“catchall”规则说这是一个有效的地址 – 它已被手动验证 – 即使它符合规则库的任何规则.
组件：
1地址由多行组成,每行具有相关的序列号和多个标签(通常为一个).也可以将地址行,他们验证的规则的一组规则和版本相关联,但这是一个取决于更新/插入/计算速率的细化.
地址标签是城市;镇;门牌号码;并识别地址的不同行.可能有一个没有任何标签的地址行,但在这种情况下,只有一般的搜索(例如纽约)才可以在整行的行上.搜索“City = New York”)是不可能的.
3以专门的语言编写的规则.这可以是正则表达式一种特定于你的语言您的正常开发语言(尽管这可能是最不有用的方法,因为编程语言可能会发现难以准确和准确地表示我正在谈论的类型的规则.代表性规则的一个例子可能是(关于你的描述美国邮政编码) –
前五个字符必须是数字.
前五个字符代表“区号”.
邮政编码必须是地址的最后一行.
规则将分为组和集(例如美国地址)规则必须能够参考其他规则以及地址数据.
>您的验证例程需要采用地址行,并将规则应用于它(通常是设置).它将返回一个布尔有效或无效的地址,以及可选的验证的规则集.
>打印程序将再次应用适当的规则集(可能与验证集不同)到地址数据,以提供格式化的地址.
我希望其他组件从整体的方法是显而易见的.
这种方法旨在处理您的问题中确定的这些问题：
>电话代码分区.
>使用中可能的区号的数量有限.
>为特定用途保留的电话号码块.
>数据的归一化 – 数据被归一化.然而,这种类型的规范化(反向索引)通常不被使用,除了数据仓库软件和包含大量实时传感器信息的数据库之外.可能在实现此解决方案时,您可能会最终选择(可控制)复制数据.这不是解决方案的固有部分,但可能很方便.
>我强烈建议不要为每个变体添加类 – 这是不可扩展的,也不是可维护的.
>搜索在下面详细介绍.
>避免怪物表 – 规则库可能是数百到数千个规则附加于实际数据的顺序.
>解决方案是可扩展的 – 只需添加或修改规则.
并处理一些相关问题.
>即使您可以将验证规则应用于国家格式的地址,对于特定国家的标准也将永远是例外.我自己的地址就是一个例子 – 我住在一条船上,需要除了邮局标准地址之外,还包含我地址中的其他信息.这种异常总是可能需要手动干预 – 因此是手动干预所接受的规则.
>不同国家的地址排序不同 – 例如中国的地址是：国家;邮政编码市;城区;街道名称;门牌号码;人名.
>从没有规则的地区接收第一个地址,并且国家的规则与您录制的地区有所不同.
>想要使用(例如办公室)的地址与“他们”地址不同的地址.
>具体个人解决问题 – 有人希望将他们的信件从他们最近和最亲爱的隐藏起来.
>解决方案可以扩展到类似的问题 – 例如指一个人.这可以涉及标题 – Dr,Rev等;乘以连字符(ffoulkes-symthe);资格(CPA,理学学士学位等)和家庭资格(第三等);以及根据人文化的多种命名方式(印度次大陆人通常没有姓氏,每个人显然都有不同的姓氏).
>可以轻松快速地改变寻址规则(例如添加新的开发新的邮政编码).
仍然出现的问题是：
>搜索将会更复杂 – 需要搜索地址的所有行和相关标签,而不是特定的地址字段
>建立这样一个规则库需要时间,而最初的规则加载可以很快地完成 – 你的问题中就有一些例子,只有在处理了多个异常和异常之后,就会出现一个完整的集合.
编辑：
当我写了我的回应时,我并没有意识到BigTable.很快看了这个,似乎是一个非常相似的概念.对于在ACID开发中实现它,我认为这对于联系人数据集和规则数据库是可能的.从经验来看,我知道它在这样一个环境中很容易扩展到5 * 10 ^ 7的联系方式(尽管有背景,联系细节的非时间关键验证).
在考虑ACID / sql的情况下,我使用“视图”这个词可能已经开始了一个我没有打算的方向.更合适的词可能是概述或展望(没有关系模型或附加DBMS货物的东西).事实上,我会把我所提到的每一件事情都视为候选人的表格.
我提出了一个方案草图,以协助讨论.该模式使用一些M：N连接,这显然在一个实现中被标准化为关联表.这为读者留下了一个练习:-).我已经把几个示例属性和数据放在一些表中.
在草图中,编辑规则集;规则;与其他规则(管理应用程序)相关的规则显然可以通过sql地址用户的正常CRUD操作使用ACID属性完成;地址;和地址行同样可以以ACID / sql的方式完成,将地址行作为用户的输入.您可能希望对交易进行一些预处理,从道路名称中分离出(在我的示例中)房屋号码,从而丢失“道路名称”规则.可能有用的其他预处理是资本化的标准化 – 尽管这也可能是验证步骤的一部分.也可以直接接受“9里士满路”的完整行,并将其标记为“需要验证”.在这两种情况下,没有问题(我知道)关于使此事务ACID.
我不清楚的是,如何将验证和后续标记合并到ACID / sql事务中.看来,为了使验证步骤为ACID,可能需要根据规则集排序测试应用程序(最常见的情况是首先测试,并在验证成功时停止).另外,为了使事务ACID可能有必要,仅针对您最常见的情况进行验证,将其他人标记为“需要验证”,然后将其作为后台任务完成.
验证的实际任务包括检查整个规则库,由set设置,直到找到一组验证所有输入行的规则.数据本身显然有潜在的指导方针 – 如果您已经记录了国家/地区,那么这两种方式都可以让您立即对国家/地区进行标记,并为您必须测试的规则集提供一个过滤器.对不起,这是迄今为止我可以采取的这个方面.
顺便提一下,这个草图只是部分地进行总体规范化.如图所示,每个地址都有自己的地址行序列,并且没有将数据超出单独行的数据标准化为输入(加或减任何您选择的预处理).通过进行地址和地址行M：N之间的链接,并确保地址行表的行字段是其主键,可以进一步采取这种方法.
当谈到这个概念的更详细的资源时,我有两个问题.
第一个(和微不足道)的一个原因是,这个概念是我的原创作品,根据我二十多年的经验,作为一名对开发环境技术和开发方法特别感兴趣的方法顾问和IT战略顾问.我的所有工作生活都在联系细节成为主要关注的环境中(出于财务和监管/立法原因).事实上,在我完成阅读你的问题之前,我对你的问题的原始回应是完整的,即使这样我花了大约四分之三的时间让它打字了.
更重要的原因是这个想法的一些来源是机密或秘密的.在我的工作生涯中,我的一部分工作涉及到技术发展的最新进展,并预测了十年时间内技术对企业的影响.这涉及访问研究实验室,并与领先的研究人员讨论了各种主题.虽然我不是,我自己是一流的研究员,但我似乎非常擅长综合他人的研究工作.但是,在这样做的时候,我一直在商业保密和/或军事保密的条件下运作.我的答案都没有违反这些条件.作为结果,我只能给出关于如何推导信息的模糊的指导方针.
我的消息来源是：
>由C J Date在IBM进行的研讨会,探索进一步的规范化和关系模型(而不是在sql中实现的关系模型).这涉及第五(？)和第六(？)正常形式的探索.
>与Oracle技术人员一段时间的讨论,讨论元数据;元数据;和其他这样的概括.
>与英国的军事研究机构进行讨论.虽然这是几年前,我不知道有没有发表过关于我们正在讨论的话题.
>在一个大型金融机构工作,其联系细节体系与我的建议非常相似,但是来源于非关系根源;在记忆力,持久记忆力和备份能力是一个主要关注的时代,原有的技术动力是节省空间的.
编辑：
我完成了上面的编辑,闭嘴了我的电脑,做了一些家务,上床睡觉,闭上眼睛,我已经解决了我在前一次编辑中无法完成的部分.
虽然在进行标签/验证时需要做更新,但实际上大部分工作正在阅读和比较.因此,它是乐观锁定的主要候选人.在伪代码中,它将如下所示：
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条件.
原文地址：https://www.jb51.cc/mssql/81603.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
