MySQL тип данных для номера телефона и адреса

Question

Я хочу ввести номер телефона в форму, включая код страны, добавочный номер

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. Что лучше для обработки?

Спасибо за ваш совет.

Answer 1

Лично я не использую числовой тип данных для хранения телефонных номеров или связанной с ними информации.

Как вы храните число, скажем, 001234567? Это закончится как 1234567, теряя ведущие нули.

Конечно, вы всегда можете набрать его слева, но при условии, что вы точно знаете, сколько цифр должно быть в числе.

Это не отвечает на весь ваш пост,
Просто мои 2 цента

Answer 2

На самом деле вы можете использовать varchar для номера телефона. Вам не нужен int, потому что вы не собираетесь выполнять арифметику с числами.

Answer 3

Сохраните их как два поля для телефонных номеров - «число» и «маска» как TinyText типы , для которых не требуется более 255 элементов .

Прежде чем сохранять файлы, мы анализируем номер телефона, чтобы определить форматирование, которое использовалось и создает маску, затем мы сохраняем номер только цифрами, например,

Ввод: (0123) 456 7890
Номер: 01234567890
Маска: (nnnn)_nnn_nnnn

Теоретически это позволяет нам выполнять сравнительный поиск в поле «Номер», например, получать все телефонные номера, начинающиеся с определенного кода города, не беспокоясь о том, как он вводится пользователями.

Answer 4

Я обычно храню телефонные номера как BIGINT в формате E164.

E164 никогда не начинается с 0, причем первые несколько цифр являются кодом страны.

+441234567890
+44 (0)1234 567890
01234 567890

и т.д.. будет храниться как 441234567890.

Answer 5

я бы использовал varchar для телефонных номеров. таким образом, вы также можете хранить + и (), которые иногда отображаются в телефонных номерах (как вы упомянули сами). и вам не нужно беспокоиться об использовании всех битов в целых числах.

Answer 6

Я не уверен, стоит ли вообще использовать целые числа. Некоторые числа могут содержать специальные символы (например, # как часть расширения), с которыми вы тоже сможете справиться. Поэтому я бы предложил вместо этого использовать varchars.

Answer 7

Рассмотрите возможность нормализации до формата E.164 . Для полной международной поддержки вам понадобится VARCHAR из 15 цифр.

См. Рекомендация Twilio для получения дополнительной информации о локализации телефонных номеров.

Answer 8

Если хранится менее 1 млн. Записей, а высокая производительность не является проблемой, используйте varchar (20) / char (20), в противном случае я обнаружил, что для хранения даже 100 млн. Глобальных бизнес-телефонов или персональных телефонов лучше использовать int. , Причина: меньший ключ -> более высокая скорость чтения / записи, также форматирование может допускать дубликаты.

1 телефон в символе (20) = 20 байтов против 8 байтов bigint (или 10 против 4 байтов int для локальных телефонов, до 9 цифр), меньше записей может входить в индексный блок => больше блоков = > больше запросов, смотрите this для получения дополнительной информации (написано для 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.

Answer 9

INT (10) не означает 10-значное число, это означает целое число с шириной отображения 10 цифр. Максимальное значение для INT в MySQL составляет 2147483647 (или 4294967295, если оно не подписано).

Вы можете использовать BIGINT вместо INT, чтобы сохранить его в виде числа. С помощью BIGINT сэкономит вам 3 байта в строке над VARCHAR (10).

Хранить «Страна + область + номер отдельно». Вы можете попробовать использовать VARCHAR (20), это позволит вам правильно хранить международные телефонные номера в случае необходимости.

Answer 10

varchar или текст должны быть лучшими типами данных для хранения мобильных номеров, я думаю.