将手机存放在三个字段中还是作为一个字段更好?
我正在努力决定将存储在 MySQL 数据库中的电话号码分开。
一种思路是将电话分解为:
- 区号 (123)
- 前缀 (123)
- 后缀 (1234)
另一种思路是将文件简单地放置在单个字段中,采用任何认为合适的格式:
- 123456789
- (123) 123-4567
- 123 -456-7890
我认为第一个更好的最初原因是能够根据从我们的会员收集的电话号码快速、轻松地收集统计数据(例如,X 个会员的区号为 123)。
真的有“正确”的方法吗?我确实意识到,与 PHP 配合使用,我可以以任何我想要的方式检索和重新格式化,但我想使用最佳实践。
感谢您的建议
编辑
我暂时只存储北美电话号码
I am struggling with the decision to separate phone numbers stored in a MySQL database.
One school of thought is to break out the phone as:
- area code (123)
- prefix (123)
- suffix (1234)
Another is to simply place the file in a single field with whatever formatting deemed appropriate:
- 123456789
- (123) 123-4567
- 123-456-7890
My initial reason for thinking the first would be better is in terms of being able to quickly and easily gather statistical data based on the phone numbers collected from our members (X number of members have a 123 area code for example).
Is there really a 'right' way to do it? I do realize that paired with PHP I can retrieve and reformat any way I want but I'd like to use best practice.
Thanks for your advice
EDIT
I will only be storing North American phone numbers for the time being
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
我投票给一个字段,在您输入数据时对其进行处理,使其采用已知的格式。我尝试了两种方法,单字段方法似乎生成的代码总体较少。
I vote for one field, processing the data as you put it in so that it's in a known format. I've tried both ways, and the one-field approach seems to generate less code overall.
您希望以最有效的方式将其存储在数据库中,正是因为它很容易在 PHP 中重新格式化。选择全数字字段,不带分隔符(1231231234),因为这将是最好的方法。如果您有国际电话号码,请同时添加国家/地区代码。然后,在您的代码中,您可以使用正则表达式对其进行格式化,以使其看起来像您想要的那样。
You want to store it in the most efficient way in the DB, precisely because it's so easy to reformat in PHP. Go for the all-numeric field, with no separators (1231231234) since that would be the best way. If you have international phone numbers, add the country code as well. Then in your code you can format it using regular expressions to look however you want it.
我会将电话号码存储为字符串,而不是数字。
电话号码是碰巧使用数字的标识符。
以零开头的电话号码是有效的,但可能会被编程语言解释为八进制。
将电话号码剥离为仅数字,并将分机号存储在单独的字段中。
这将允许稍后统一格式。
对于美国,去掉前面的“1”数字(并根据字符串的长度确定格式(美国为 10 位数字))。
I would store phone numbers as strings, not numbers.
Phone numbers are identifiers that happen to use digits.
Phone numbers starting with zero are valid, but may be interpreted as octal by a programming language.
Strip the phone number to only digits and store the extension in a separate field.
This will allow for uniform formatting later.
For US, strip the prepending ’1′ digit (and determine formatting based on length of the string (10 digits for US)).
我正在构建一个呼叫中心应用程序(它管理一组分布式呼叫者联系的联系信息队列),并且该体系结构指定了一个字段,没有空格、破折号等。经过大量分析后,我同意这似乎是最好的。
根据电话号码输入的可变性(撇号、点、破折号及其组合),我构建了一个简单的函数来处理用户输入,剥离除数字本身之外的所有内容,以及重新格式化原始数据的“重建器”数字变成对用户更具视觉吸引力的东西。
因为它们对我很有帮助,所以到目前为止我所写的内容如下:
一些注意事项:我的应用程序目前不适用于国际客户(其中内置了一个 voip 应用程序,我们不想允许外部呼叫)现在是美国)所以我没有花时间为国际可能性做好准备。另外,随着这项工作的进展,我可能会在稍后返回重构并支持这些功能。
到目前为止,我发现了一个让我有点痛苦的弱点。在我的应用程序中,我必须禁止根据一天中的时间按时区拨打电话(例如,不允许在东部上午 9:00 时拨打西海岸的某人在上午 6:00 的电话)为此,我必须通过比较 3 位数的区号来获取时区,将单独的区号表与电话号码连接到我的表中。但我不能简单地将邮政编码与我的电话号码字段进行比较,因为它们永远不会匹配。因此,我必须处理额外的 SQL 才能获取数字的前三位。虽然这不是游戏规则的改变者,但仍然需要更多的工作和混乱。
I'm in the process of building a callcenter application (it manages queues of contact information for a group of distributed callers to contact) and the architecture specified one field, no spaces, dashes, etc. After quite a bit of analysis, I agree it seems the best.
Based on the variability of entry for phone numbers (apostrophes, dots, dashes, and combinations of each) I built a simple function that deals with user entry, stripping down all but the numbers themselves, and also a "rebuilder" that reformats the raw number into something that's more visually appealing to the user.
Since they've been helpful to me, here's what I've written so far:
Some caveats: My app is not available for international customers right now (there's a voip application built into it that we don't want to allow to call outside of the US right now) so I've not taken the time to setup for international possibilities. Also, as this is in progress, I will likely return to refactor and bolster these functions later.
I've found one weakness so far that has been a bit of a pain for me. In my app, I have to disallow calls to be made by timezone based on the time of day (for instance, don't allow someone on the West Coast to be called at 6:00am when it's 9:00am in the East) To do that, I have to join a separate area code table to my table with the phone numbers by comparing 3 digit area codes to get the timezone. But I can't simply compare the zip code to my phone number field, because they'd never match. So, I have to deal with additional SQL to get just the first three digits of the number. Not a game-changer, but more work and confusion nonetheless.
一定要将它们作为文本字符串存储在一个字段中,并且只存储数字。这样想吧;不管是什么号码,都是一个电话号码。然而,数字的分段取决于许多因素(地点、提供的数字数量,甚至个人偏好)。更容易存储该内容并在以后通过文本操作进行更改。
Definitely store them in one field as a text string, and only store the numbers. Think of it this way; no matter what the numbers are, its all one telephone number. However, the segmenting of the numbers is dependent on a number of things (locality, how many numbers provided, even personal preference). Easier to store the one and change it later with text manipulation.
我认为如果您想使用区号作为过滤器,将数字拆分为 3 个字段是最好的选择,否则,您应该只使用 1 个字段。
如果您打算将它们存储为数字,请记住使用
ZEROFILL
;)I think splitting the number in 3 fields is the best options if you want to use area codes as filters, otherwise, you should only use 1 field.
Remember to use
ZEROFILL
is you plan on storing them as numbers ;)这实际上取决于几个因素:
不管怎样,我只会存储数字,在 MySQL 或 PHP 中格式化并添加括号和破折号很容易。
除非我要按区号进行搜索日志,否则我会将整个电话号码放入一个字段中,因为我假设大多数时候您都会检索整个电话号码。
如果您将来可能会使用国际号码:
您可能需要添加一个国家/地区字段,这样您在处理号码时就不必猜测它们来自哪个国家/地区。
it really depends on a couple factors:
No matter what, I would only store numbers, it's easy enough to format either in MySQL or PHP and add parentheses and dashes.
Unless I was going to do a log of searching by area code, I would just put the entire phone number into a single field since I assume most of the time you would be retrieving the entire phone number anyway.
If it's possible that you will take international numbers in the future:
You might want to add a country field though, that way you won't have to guess what country they are from when dealing with the number.
您使用什么取决于您计划如何使用数据以及程序将在何处使用。
如果你想通过区号高效地搜索记录,那么就把区号拆分出来;当查询进行简单的字符串比较时,与对完整电话号码进行字符串操作以获取区号相比,查询的执行速度要快得多。
但是,请注意,格式为 XXX-XXX-XXXX 的电话号码仅在美国、加拿大和其他受 NANPA 系统管辖的较小的加勒比地区找到。世界其他各个地区(欧盟、非洲、东盟)的编号标准截然不同。在这种情况下,拆分出“区号”的等效项可能没有意义。另外,如果您只想向用户显示电话号码,则只需将其存储为字符串即可。
是否以某种格式存储数字主要取决于个人喜好。存储原始数字可以轻松更改格式;您可以通过更改几行代码从 XXX-XXX-XXXX 变为 (XXX) XXX-XXXX,而不是重新格式化您已有的 1000 万个数字。从电话号码中删除特殊字符也是一个相对简单的正则表达式。不格式化存储还可以为每个数字节省几个字节,并允许您使用固定长度字段(进一步节省 varchar 固有的数据开销)。这可能在存储非常宝贵的移动应用程序中有用。然而,您服务器机房中的 5 TB 分布式 SQL 集群可能不会注意到 char(10) 和 varchar(15) 之间有太大差异。将它们格式化存储还可以加快数据加载速度;您不必先对其进行格式化,只需将其从数据库中拉出并将其粘贴到页面上即可。
What you use depends on how you plan to use the data, and where the program will be used.
If you want to efficiently search records by area code, then split out the area code; queries will perform much faster when they're doing simple string comparisons versus string manipulation of the full phone number to get the area code.
HOWEVER, be advised that phone numbers formatted XXX-XXX-XXXX are only found in the US, Canada, and other smaller Caribbean territories that are subject to the NANPA system. Various other world regions (EU, Africa, ASEAN) have very different numbering standards. In such cases, splitting out the equivalent of the "area code" may not make sense. Also, if all you want to do is display a phone number to the user, then just store it as a string.
Whether to store a number with a format or not is mostly personal preference. Storing the raw number allows the formatting to be changed easily; you could go from XXX-XXX-XXXX to (XXX) XXX-XXXX by changing a couple lines of code instead of reformatting the 10 million numbers you already have. Removing special characters from a phone number is also a relatively simple Regex. Storing without formatting will also save you a few bytes per number and allow you to use a fixed-length field (saving further data overhead inherent in varchars). This may be of use in a mobile app where storage is at a premium. However, that 5-terabyte distributed SQL cluster in your server room is probably not gonna notice much difference between a char(10) and a varchar(15). Storing them formatted also speeds up loading the data; you don't have to format it first, just yank it out of the DB and plaster it on the page.