在SQL Server 2005中应使用哪种数据类型存储电话号码?


82

我需要将电话号码存储在表格中。请建议使用哪种数据类型? 等待。请在继续阅读之前继续阅读。

由于销售代表可以使用此字段进行搜索(包括通配符搜索),因此需要对该字段进行大量索引。

到目前为止,我们希望电话号码有多种格式(来自XML文件)。是否需要编写解析器以转换为统一格式?可能有数百万的数据(重复的数据),我不想每次通过某些源数据时都占用服务器资源(在诸如预处理等活动中)。

任何建议都欢迎。

更新:我无法控制源数据。只是xml文件的结构是标准的。希望将xml解析保持在最低水平。一旦进入数据库,检索就应该很快。这里出现的一个疯狂建议是,它甚至应该与Ajax AutoComplete功能一起使用(这样,销售代表可以立即看到匹配的功能)。我的天啊!!


您可能要使用github.com/googlei18n/libphonenumber来解析/清除源数据。
Nicholas Hirras,

Answers:


58

这是否包括:

  • 国际号码?
  • 扩展程序?
  • 除了实际数字以外的其他信息(例如“问鲍比”)?

如果所有这些都不是,我将使用10个字符的字段并去除所有非数字数据。如果第一个为是,其他两个为否,则我将使用两个varchar(50)字段,一个用于原始输入,一个将所有非数字数据划分为条带并用于索引。如果2或3是,我想我会做两个字段和某种疯狂的解析器来确定什么是扩展或其他数据并适当地对其进行处理。当然,您可以通过对索引进行某些操作来避免第二列,该索引在创建索引时会去除多余的字符,但是我只想做第二列,并可能使用触发器来去除字符。

更新:为了解决AJAX问题,它可能没有您想象的那么糟糕。如果实际上这是对表执行任何操作的主要方式,请按照我所说的那样仅将数字存储在第二列中,然后将该列的索引聚为一组。


是的,所有问题都可以。我无法控制源数据。那里有一些好的建议。谢谢。
John

12
我很挑剔,但是10个字符的字段不能覆盖大多数英国移动电话号码和许多英国固定电话号码。即使在美国,也允许超过10个,以便将来扩展电话号码。
乔恩·埃格顿

2
为什么不decimal(10,0)代替char呢?
安德森先生

1
@MrAnderson,我认为这是因为decimal(10,0)你必须垫前导零放回数只要你需要它..
Mathijs Flietstra

根据您所在的世界,我认为10个字符不够长,正如Brad的回答所强调的那样。
查迪西莫(Richardissimo)

42

我们使用varchar(15)并在该字段上肯定使用索引。

原因是国际标准最多可以支持15位数字

维基百科-电话号码格式

如果您确实支持国际号码,建议您单独存储世界区号或国家/地区代码,以更好地过滤查询,以免您自行解析和检查电话号码字段的长度以限制返回美国的电话例


2
我可能忽略了一些显而易见的事情,但是使用字符数据类型存储数字数据有什么好处?而且,如果您要存储的数字数据以外的数据(例如,定界符),那么您是否不需要超过15个字符来存储格式化的15位数字?
FtDRbwLXw6 2012年

13
@drrcknlsn原因是前导零-一些(在某些国家/地区中大多数都是以零开头)
Manse

15
@drrcknlsn我知道此评论已有2年历史了,但是如果有人遇到您的评论,通常:经验法则是应使用整数数据类型存储有意义的数字数据,其余的是字符串。例如,添加两个电话号码或乘以SIN / SSN号码是没有意义的,因此应将它们存储为字符串。
Marco Pietro Cirillo 2014年

2
@drrcknlsn为什么不decimal(10,0)那么代替char呢?
安德森先生

@Mr A:可能是因为电话号码的长度可能因一个地区/国家而异。用前导零填充会产生一个附加的解析问题。
干线


3

我可能在这里没有发现明显的地方,但是varchar是否不能足够长以至于您期望的最长电话号码正常工作?

如果我缺少明显的东西,我喜欢它,如果有人会指出来...


3

我会使用varchar(22)。足够大,可以容纳带有分机号的北美电话号码。您可能希望去除所有讨厌的'(',')','-'字符,或仅将它们解析为一种统一格式。

亚历克斯


2

SQL Server 2005对索引的varchar字段中的文本的子字符串查询进行了很好的优化。在2005年,他们为索引字段的字符串摘要引入了新的统计信息。这对于全文搜索有很大帮助。


2

使用varchar效率很低。使用货币类型并在其中创建一个用户声明的类型“电话号码”,并创建一个规则,仅允许使用正数。

如果您将其声明为(19,4),则您甚至可以存储4位扩展名,并且足以容纳国际号码,并且仅占用9个字节的存储空间。此外,索引速度很快。


2
。-1。崇高而不是阅读-占%233%-全表扫描+转换?这是一个标准问题,有一个标准解决方案,不是数字。删除所有格式,顺便说一句。
TomTom

@TomTom虽然我同意money这不是答案,但是如果不需要按子字符串搜索(我想很多人不需要仅根据一部分电话号码查找记录),那么使用会出现什么问题decimal(10,0)呢?
安德森先生

1

使用nvarchar进行预处理,以使其尽可能标准化。您可能需要提取扩展并将其存储在另一个字段中。


1

规范化数据,然后将其存储为varchar。规范化可能很棘手。

那应该是一次性的打击。然后,随着新记录的出现,您正在将其与规范化数据进行比较。应该很快。


1

由于您需要容纳许多不同的电话号码格式(可能包括分机号等),因此像对待其他varchar一样对待它可能是最有意义的。如果您可以控制输入,则可以采取多种方法来使数据更有用,但事实并非如此。

一旦决定简单地将其视为任何其他字符串,您就可以集中精力克服不可避免的问题,包括不良数据,神秘的电话号码格式以及其他任何会弹出的问题。挑战将在于为数据建立良好的搜索策略,而不是我认为如何存储数据。必须处理您无法控制的大量数据,这始终是一项艰巨的任务。


1

使用SSIS提取和处理信息。这样,您将可以处理与SQL Server分离的XML文件。如果需要,您也可以在单独的服务器上进行SSIS转换。使用VARCHAR以标准格式存储电话号码。NVARCHAR是不必要的,因为我们在谈论数字,也许还有其他几个字符,例如'+','','(',')'和'-'。



1

通常用“ x”或“ ext”来表示扩展名,所以允许使用15个字符(以获得完整的国际支持)加上3个字符(“ ext”)加4个(扩展名本身),总共22个字符。那应该使您安全。

或者,对输入进行归一化,以便将任何“ ext”转换为“ x”,最多为20。


1

对于电话等多值属性,最好有单独的表。

由于您无法控制源数据,因此可以解析XML文件中的数据并将其转换为正确的格式,这样特定国家/地区的格式就不会有任何问题,并将其存储在单独的表中,以便建立索引和检索都将是有效的

谢谢。


没有完全回答问题。
Smart Manoj


0

请改用long数据类型。不要使用int,因为它只允许-32,768和32,767之间的整数,但是如果您使用long数据类型,则可以在-2,147,483,648和2,147,483,647之间插入数字。


1
很好,但是您不能使用国家/地区代码存储国际号码,因为有些数字以国家/地区代码开头。例如:0094777123123,最好使用带有正则表达式验证的varchar(15)字段。
Bubashan_kushan
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.