我应该在SQL的varchar(length)电话中考虑的最长的全球电话号码是多少


200

我应该在SQL varchar(length)电话中考虑的最长的全球电话号码是什么。

注意事项:

  • +国家代码
  • ()用于区号
  • x + 6个数字作为扩展名扩展名(因此请使其为8 {space})
  • 组之间的空格(即,在美国电话中+ x xxx xxx xxxx = 3个空格)
  • 这是我需要您帮助的地方,我希望它能遍布全球

考虑到在我现在的特殊情况下,我不需要卡等。号码以国家代码开头,以分机号结尾,不需要传真/电话等注释,也不需要电话卡东西。


1
我认为将数字转换为长值将是一个很好的解决方案,它将仅需要64位空间,我使用了多年,没有问题


1
@MattDiPasquale已经在这里提到,但是谢谢!
Shimmy Weitzhandler,2015年

2
是的,但是答案不包括我给的链接。别客气。:-)
ma11hew28'5

Answers:


79

考虑到varchar(30)和varchar(100)之间没有开销差异,如果每个字符仅存储20个字符,请谨慎行事,将其设置为50个字符。


26
仅出于了解:那么什么时候会有开销?请在您的答案中包含一个来源,以便我们继续学习并从中学习基础。
Shimmy Weitzhandler,2010年

6
我知道情况确实如此,但并非总是如此。例如,在MySQL中,全长用于排序。最好至少花一些力气。
Morgan Tocker

15
两列大小之间没有存储大小差异。取决于您的特定数据库,很可能会有开销,无论是开销还是其他开销。例如,SQL Server失去了很多预测数据页大小并因此优化访问和对齐的能力。与往常一样,进行测试。
Matt Enright

16
过早的优化是万恶之源。
Harindaka 2013年

78
普通的概括甚至更糟。设计一个系统时考虑的优化是从来没有 邪恶 本身 -优化变得邪恶时,一个致力于过多的时间量不必要的,不易察觉的轻微效率。
jbowman 2015年

167

假设您不存储'+','(()','-',空格和您拥有的东西(以及您为什么要存储这些东西),它们是表示形式的关注点,会因当地习俗和网络分布而异无论如何),针对国际电话网络(大多数国家网络通过其连接)的ITU-T建议E.164规定了完整的号码(包括国家代码,但不包括诸如拨出所需的国际呼叫前缀之类的前缀,视国家/地区而异,且不包括后缀,例如PBX分机号)最多15个字符

呼叫前缀取决于呼叫者,而不取决于被呼叫者,因此(在许多情况下)不应与电话号码一起存储。如果数据库存储的是个人通讯录的数据(在这种情况下,应存储国际电话前缀),则您必须处理的最长国际前缀(根据Wikipedia在芬兰,)为5位数字。

至于后缀,某些PBX最多支持11位分机号(同样, 根据Wikipedia)。由于PBX分机号是不同拨号计划的一部分(PBX与电话公司的交换机分开),所以分机号必须与电话号区分开,可以使用分隔符或将其存储在不同的列中。


5
如果您不存储格式字符(例如'+','((',')','-'和''),并且要存储来自不同国家的数字,则可能需要添加一列以指示格式显示号码时的号码类型。
三叉戟

38
底线:15字符。如果存储前缀和后缀,则底线是:5 + 15 + 11 = 31
2014年

3
@MattEnright,我认为您应该在回答中更新AlikElzin的评论
Shimmy Weitzhandler,2015年


17

在GSM规范3GPP TS 11.11中,在MSISDN EF(6F40)中为“拨号号码”预留了10个字节。由于这是电话号码的GSM表示形式,并且其用法已被半字节交换(并且总是有括号的可能性),因此22个字符的数据应该足够。

根据我的经验,只有一个开/关括号的实例,这就是我对以上原因的理解。


10

更糟糕的是,我使用电话卡拨打国际电话,因此它在美国的本地号码+帐号(6位数字)+密码(4位数字)+“暂停” +您上面所述的内容。

我怀疑可能还有其他情况


2
您的观点很好。我在味精中添加了几行,请读
Shimmy Weitzhandler

10
但是,电话卡重拨不应该在数据库中-这是根据拨号规则拨号时添加的部分。存储的号码应采用ISO格式,没有任何与拨号相关的信息。
TomTom 2010年
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.