SQL Мобильный телефон — char или int?
В каком типе поля SQL лучше хранить мобильный телефон — char или int?
в начале было слово «+»
Chukcha, а зачем хранить +? Например, я захочу получить номера определенного оператора, LIKE для CHAR будет настолько же производителен, как и диапазон для INT?
Ок. Храните в двух полях — форматированное по вашему желанию
и чистое от формата 🙂
Если хотите использовать для поиска — char без формата номера, для быстрого доступа — отформатировнный
А еще. отдельным полем код оператора
лучше всего в varchar
будет смотреться гармоничнее, нежели
да и пользоваться тоже удобнее
Храните номера в соответствии со стандартом E.164. Символы, отличные от цифр, не нужны.
Хранить в varchar. Сами так храним.
Попробуйте для теста записать 9999999999 в поле int
unsigned int имеется в виду.
Я бы масштабируемость сразу бы заложил.
3 поля: регион, код сети, номер телефона.
Допустим расширяемость, отчеты, да многое можно будет оптимизировать потом.
И выводить проще, если в отдельных полях будет )
Друзья, объясните, когда можно использовать один KEY для двух значений? Вот у меня есть номер телефона, который разбит на FOREIGN KEY `country` и непосредственно сам номер телефона. Я не вижу смысл создавать отдельные ключи для страны и номера, могу ли я сделать один ключ? Или для выборки это не катит? Нужно будет выбирать конкретный номер телефона, то-есть, выборка за `phone`, но использовать форматирование вывода в зависимости от `country`.
Если я хочу, чтобы целый номер country + phone был уникальным, по аналогии, нужно создавать один ключ UNIQUE?
MySQL тип данных для номера телефона и адреса
Если tel_number больше 15 бит, какой тип данных я могу использовать, лучше использовать Bigint(20) ?
Например, если у меня есть код страны для Канады, я могу использовать +2 или 002. Что лучше для обработки?
Спасибо за ваш совет.
10 ответов
Ну, лично я не использую числовой тип данных для хранения телефонных номеров или связанной информации.
Как вы храните номер, скажем 001234567? Это закончится как 1234567, потеряв ведущие нули.
Конечно, вы всегда можете оставить его, но при условии, что вы точно знаете, сколько цифр должно быть.
Это не ответит на весь ваш пост,
Только мои 2 цента
На самом деле вы можете использовать varchar для номера телефона. Вам не нужен int, потому что вы не собираетесь выполнять арифметику по номерам.
Просто добавьте 2p опыта реального мира.
Мы сохраняем 2 поля для телефонных номеров — «число» и «маску». Оба они хранятся в виде типов TinyText
Прежде чем мы храним файлы, мы проанализируем номер телефона, чтобы получить форматирование, которое было использовано и которое создает маску, затем мы сохраняем число цифр только, например.
Вход: (0123) 456 7890
Номер: 01234567890
Маска: (nnnn)_nnn_nnnn
Теоретически это позволяет нам выполнять сравнения в поле «Число», например, получать все номера телефонов, начинающиеся с определенного кода области, без необходимости беспокоиться о том, как они были введены пользователями
Я обычно храню телефонные номера как BIGINT в формате E164.
E164 никогда не начинается с 0, причем первые несколько цифр являются кодом страны.
и т.д.. будет храниться как 441234567890 .
я бы использовал varchar для телефонных номеров. Таким образом, вы также можете хранить + и(), что иногда можно увидеть в телефонных номерах (как вы упомянули сами). и вам не нужно беспокоиться о том, чтобы использовать все биты в целых числах.
Я не уверен, стоит ли вообще использовать целые числа. Некоторые номера могут содержать специальные символы (например, часть расширения), с которыми вы также можете справиться. Поэтому я бы предложил использовать varchars.
Рассмотрим нормализацию формата E.164. Для полной международной поддержки вам понадобится VARCHAR из 15 цифр.
Подробнее о локализации телефонных номеров см. рекомендацию Twilio.
Если хранить менее 1 млн записей, а высокая производительность — это не проблема для varchar (20)/ char (20), в противном случае я обнаружил, что для хранения даже 100 миллионов глобальных телефонных телефонов или персональных телефонов int лучший. Причина: меньший ключ → более высокая скорость чтения/записи, а также форматирование может допускать дубликаты.
1 телефон в char (20) = 20 байт по сравнению с 8 байтами bigint (или 10 vs 4 байта int для локальных телефонов, до 9 цифр), меньше записей можно ввести индексный блок = > больше blocks = > больше запросов, см. this для получения дополнительной информации (writen для Mysql, но это должно быть верно для других реляционных баз данных).
Вот пример телефонных таблиц:
или с обработкой/разбиением перед вставкой (2 + 2 + 4 + 1 = 9 байтов)
Также «номер телефона не является числом», на мой взгляд, относится к типу телефонных номеров. Если мы говорим о внутреннем мобильном телефоне, то строки все в порядке, так как пользователь может пожелать сохранить GSM Hash Codes. Если вы храните E164, лучше всего выбрать bigint.
INT (10) не означает 10-значное число, это означает целое число с шириной отображения 10 цифр. Максимальное значение для INT в MySQL составляет 2147483647 (или 4294967295, если без знака).
Вы можете использовать BIGINT вместо INT, чтобы сохранить его как числовое. С помощью BIGINT сохранит вам 3 байта в строке над VARCHAR (10).
Чтобы сохранить «Страна + область + номер отдельно». Вы можете попробовать использовать VARCHAR (20), это позволит вам правильно хранить международные телефонные номера, если это необходимо.
Вопрос по типу данных в SQL
Для хранения номера телефона через тире можно использовать тип данных CHAR или VARCHAR.
Например, можно создать столбец с типом данных VARCHAR(8), чтобы хранить номер телефона в формате "23-23-22". Для этого используйте команду CREATE TABLE в SQL:
После создания таблицы, вы можете добавлять записи, указывая номер телефона в формате "23-23-22":
Замените MyTable на имя вашей таблицы и убедитесь, что размер VARCHAR достаточен для хранения наибольшего номера телефона в вашей базе данных.
mysql datatype for telephone number and address
If tel_number is larger than 15 bit, which datatype can I use, I’d better use Bigint(20) ?
For example, if I have a country code for Canada I can use +2 or 002. Which is better for processing?
Thanks for your advice.
11 Answers 11
Well, personally I do not use numeric datatype to store phone numbers or related info.
How do you store a number say 001234567? It’ll end up as 1234567, losing the leading zeros.
Of course you can always left-pad it up, but that’s provided you know exactly how many digits the number should be.
This doesn’t answer your entire post,
Just my 2 cents
Actually you can use a varchar for a telephone number. You do not need an int because you are not going to perform arithmetic on the numbers.
Store them as two fields for phone numbers — a «number» and a «mask» as TinyText types which do not need more than 255 items.
Before we store the files we parse the phone number to get the formatting that has been used and that creates the mask, we then store the number a digits only e.g.
Input: (0123) 456 7890
Number: 01234567890
Mask: (nnnn)_nnn_nnnn
Theoretically this allows us to perform comparison searches on the Number field such as getting all phone numbers that begin with a specific area code, without having to worry how it was input by the users
I usually store phone numbers as a BIGINT in E164 format.
E164 never start with a 0, with the first few digits being the country code.
etc. would be stored as 441234567890 .
i would use a varchar for telephone numbers. that way you can also store + and (), which is sometimes seen in tel numbers (as you mentioned yourself). and you don’t have to worry about using up all bits in integers.
I’m not sure whether it’s a good idea to use integers at all. Some numbers might contain special characters (# as part of the extension for example) which you should be able to handle too. So I would suggest using varchars instead.
If storing less then 1 mil records, and high performance is not an issue go for varchar(20)/char(20) otherwise I’ve found that for storing even 100 milion global business phones or personal phones, int is best. Reason : smaller key -> higher read/write speed, also formatting can allow for duplicates.
1 phone in char(20) = 20 bytes vs 8 bytes bigint (or 10 vs 4 bytes int for local phones, up to 9 digits) , less entries can enter the index block => more blocks => more searches, see this for more info (writen for Mysql but it should be true for other Relational Databases).
Here is an example of phone tables:
or with processing/splitting before insert (2+2+4+1 = 9 bytes)
Also «the phone number is not a number», in my opinion is relative to the type of phone numbers. If we’re talking of an internal mobile phoneBook, then strings are fine, as the user may wish to store GSM Hash Codes. If storing E164 phones, bigint is the best option.