假设您正在处理您的正常联系人数据库(您知道...姓名,电话号码,地址,电子邮件等...).如果你在当地对此表示不满,那么处理这个问题通常不是一个大问题,但是当我们看到国际集时,它就是.
看着电话号码系统,你会认为这很简单,但事实并非如此.在北美,我们通常有1-222-333-4444格式用于呼叫人.这当然分为您的国际拨号代码,区号,交换前缀和行号.问题:实际电话号码是有限的,美国大约有220个区号在潜在的1000个区域内,每个区号只有有限数量的交换机,并且线路号码仅限于该国家/地区的特定用途(例如, 911的模式受到限制,只有10,000个中的约3/4在使用中.把这个带到英国,他们有自己的行号规则,例如保留0300-0399块的大部分特定用途,以及其他限制.国际代码也是有限的.规范区号,交换,并将数据验证检查放到电话号码上变得复杂了.我不会详细说明我们何时进入不属于该地区的地方NPA计划,但我们只是确定我们不能真正信任北美模板,踢回去,并称之为一天.
我们如何规范这样的事情？我们如何验证数据？我们如何处理这些看似临时的扩展代码或内部拨号指令？
国际地址不是更好,不仅保留数据之间的差异,而且输出格式也不尽相同.我们如何处理国际邮政编码,加拿大的格式是A1A1A1,而美国的系统如55555 [-4444]？
当我遇到它们时,我很想为每种情况编写类,将它们作为XML/JSON /类似存储在数据库中,但是我如何关联字段并轻松搜索我的内容？我不想最终为每个国家创建数千张表的表格.我想要一个易于扩展的解决方案,我可以规范我的地址并验证内容.这要问太多了吗？
validation database-design normalization internationalization