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

时间:2010-09-27 15:31:58

标签: validation database-design internationalization normalization

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

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

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

International addresses并不是更好,不仅保留数据之间的差异,而且输出格式也不尽相同。我们如何处理国际邮政编码,在加拿大时格式为A1A1A1,而美国有一个系统如55555 [-4444]?

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

3 个答案:

答案 0 :(得分:8)

答案 1 :(得分:0)

至少可以already answered获取电话号码。您可以为邮政编码做类似的事情。

答案 2 :(得分:0)

如果我实现这一点,我会将电话号码,邮政编码等保存为常规字符串。特别是数据应该以最终用户需要的格式存储。 (假设每个最终用户都有相同的需求。)例如有一个德国地址:“路名123”,美国地址? “123路名”。对邮政编码执行相同操作,将它们与城市名称相结合。您可以将地址保存为address_line_1(街道名称,用户输入的国家特定顺序的门牌号码),address_line_2(邮政编码,城市名称......)。

如果您仍需要在数据库中搜索特定的邮政编码,您可以编写正则表达式甚至是函数。考虑到城市名称,您可以将它们从address_line_2中删除,并且很可能最终得到邮政编码。

我认为为每个国家编写验证必须是巨大的工作,那是200个国家......你怎么能确定你没有错过一些当地的公约?您可以编写一个函数eq,例如计算eq(“ABCDE-34”,“ABCDE.34”)== true。

虽然我没有真正看到编写客户端服务器端验证的重点。即使客户端是Web浏览器,您也可以通过AJAX使用服务器的验证。

最终它取决于您使用的DBMS(支持Java存储过程?),您的客户端语言......还有如何输入数据(是否在Web浏览器中输入非常不准确?)和你想用它做什么。 (您是否打算使用数据库中的电话号码为Skype提供数据,或者这些电话号码是由在手机中输入的人员阅读的?)您是否需要进行一些特定的连接操作?当然,这取决于你能够花多少工时来解决这个问题......