тип данных mysql для номера телефона и адреса
Я хочу ввести номер телефона в форме, включая код страны, расширение
create table if not exists employee( `
country_code_tel int(11),
tel_number int(10),
extension int(10),
mobile bigint(20)
);
Если tel_number больше 15 бит, какой тип данных я могу использовать, мне лучше использовать Bigint(20)
?
create table address(
address varchar(255),
city varchar(255),
country varchar(255),
post_code int(11)
);
например, если у меня есть код страны для Канады я могу использовать +2 или 002. Что лучше для обработки?
Спасибо за совет.
10 ответов
ну, лично я не использую числовой тип данных для хранения телефонных номеров и другая информация.
Как вы храните номер, скажем, 001234567? Это закончится как 1234567, потеряв ведущие нули.
конечно, вы всегда можете оставить его, но это при условии, что вы точно знаете, сколько цифр должно быть.
Это не ответ на весь ваш пост,
Просто мои 2 цента
на самом деле вы можете использовать varchar для телефонного номера. Вам не нужен int, потому что вы не собираетесь выполнять арифметику на числах.
храните их как два поля для телефонных номеров - " номер "и" маска " как TinyText
типы которые не нуждаются в более чем 255 пунктов.
прежде чем хранить файлы, мы анализируем номер телефона, чтобы получить форматирование, которое было использовано, и которое создает маску, мы затем храним число только цифры, например
вход: (0123) 456 7890
Номер:01234567890
Маска:(nnnn)_nnn_nnnn
теоретически это позволяет нам выполнять поиск по числовое поле, такое как получение всех телефонных номеров, которые начинаются с определенного кода области, без необходимости беспокоиться о том, как это было введено пользователями
Я обычно храню телефонные номера как BIGINT в формате E164.
E164 никогда не начинается с 0, причем первые несколько цифр являются кодом страны.
+441234567890
+44 (0)1234 567890
01234 567890
etc. будет храниться как 441234567890
.
Я бы использовал varchar для телефонных номеров. таким образом, вы также можете хранить + и (), что иногда видно в номерах tel (как вы сами упомянули). и вам не придется беспокоиться об использовании всех битов в целых числах.
Я не уверен, что это хорошая идея использовать целые числа вообще. Некоторые числа могут содержать специальные символы (например, # как часть расширения), которые вы также можете обрабатывать. Поэтому я бы предложил использовать varchars.
если хранение менее 1 млн записей, а высокая производительность не является проблемой для varchar (20) / char(20) в противном случае я обнаружил, что для хранения даже 100 миллионов глобальных бизнес-телефонов или личных телефонов int лучше всего. Причина: меньший ключ - > более высокая скорость чтения / записи, также форматирование может допускать дубликаты.
1 телефон в char (20) = 20 байт против 8 байт bigint
(или 10 против 4 байт int
для местных телефонов, до 9 цифр), меньше записей может ввести блок индекса => больше блоков = > дополнительные поиски, см. этой для получения дополнительной информации (writen для Mysql, но это должно быть верно для других реляционных баз данных).
вот пример телефонных таблиц:
CREATE TABLE `phoneNrs` (
`internationalTelNr` bigint(20) unsigned NOT NULL COMMENT 'full number, no leading 00 or +, up to 19 digits, E164 format',
`format` varchar(40) NOT NULL COMMENT 'ex: (+NN) NNN NNN NNN, optional',
PRIMARY KEY (`internationalTelNr`)
)
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin
или с обработкой/разделение перед вставкой (2+2+4+1 = 9 байт)
CREATE TABLE `phoneNrs` (
`countryPrefix` SMALLINT unsigned NOT NULL COMMENT 'countryCode with no leading 00 or +, up to 4 digits',
`countyPrefix` SMALLINT unsigned NOT NULL COMMENT 'countyCode with no leading 0, could be missing for short number format, up to 4 digits',
`localTelNr` int unsigned NOT NULL COMMENT 'local number, up to 9 digits',
`localLeadingZeros` tinyint unsigned NOT NULL COMMENT 'used to reconstruct leading 0, IF(localLeadingZeros>0;LPAD(localTelNr,localLeadingZeros+LENGTH(localTelNr),'0');localTelNr)',
PRIMARY KEY (`countryPrefix`,`countyPrefix`,`localLeadingZeros`,`localTelNr`) -- ordered for fast inserts
)
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin
;
также "номер телефона не является номером", на мой взгляд, относительно типа телефонных номеров. Если мы говорим о внутренней мобильной телефонной книге, то строки в порядке, как пользователь может пожелать магазин GSM хэш-коды. Если хранить E164 телефоны, bigint-лучший вариант.
рассмотрим нормализацию до Е. 164. Для полной международной поддержки вам понадобится VARCHAR из 15 цифр.
посмотреть рекомендация Twilio для получения дополнительной информации о локализации телефоны.
INT (10) не означает 10-значное число, это означает целое число с шириной отображения 10 цифр. Максимальное значение для INT в MySQL-2147483647 (или 4294967295, если без знака).
вы можете использовать BIGINT вместо INT для хранения его как числового. С помощью BIGINT сохранит вам 3 байта в строке над VARCHAR (10).
хранить "страна + область + номер отдельно". Вы можете попробовать использовать VARCHAR (20), это позволяет вам хранить международные номера телефонов, если возникнет необходимость.