Тип данных для номера телефона: VARCHAR, INT или BIGINT?

Так что это будет дурацкий вопрос года, но мне нужно его задать, поскольку я не первый раз прохожу через это. Взгляните на следующее определение таблицы:

Взгляните на столбец, from_numberкоторый VARCHAR(45)прямо сейчас, но он будет содержать номер телефона. Поскольку я не знаю, сколько номеров может иметь телефон во всем мире, я стараюсь охватить почти все из них. Я хочу сохранить целостность базы данных настолько, насколько это возможно, поэтому я считаю, что VARCHARэто неправильный тип для хранения такого рода информации - может быть, я ошибаюсь, вы говорите мне, - так что я думаю об изменениях INTили даже BIGINT.

Когда я определяю столбец в Workbench, я должен указывать число в скобках ()не во всех случаях, а в тех, о которых я упоминал ранее. Так что, если я сделаю это: BIGINT()я получил эту ошибку:

Который ведет меня, чтобы прочитать немного об этом типе MySQL здесь . В основном информация такова:

Большое целое число. ... Диапазон без знака от 0 до 18446744073709551615.

Что заставляет меня спросить: какое значение я должен установить для скобок, когда я определяю BIGINT()тип. (Я использую BIGINT, потому что я не знаю, может ли INT хранить столько номеров, сколько может иметь телефон - возможно, я тоже ошибаюсь). Как правильно создать дизайн колонки в базах данных MariaDB / MySQL?

В любом случае я хотел бы узнать ваше мнение, опыт и, конечно, я хотел бы получить ответ

Примечание: я использую последнюю версию MySQL Workbench для создания диаграммы ER. Я использую также MariaDB 10.0.x

Как бы вы справились с номером телефона с добавочным номером, например «+ 1-000-000-0000 доб 1234»?

Обратите внимание, что «+» означает, что должны применяться международные правила набора номера; поэтому из Северной Америки система автоматически знает «011» перед международными вызовами и т. д.

А как насчет телефонных номеров, таких как «1-800-DBA-HELP»?

Я обычно храню номера телефонов в виде текста. Сказав это, это действительно зависит от того, насколько важен столбец вашего номера телефона. Если вы используете автоматические номеронабиратели из этого столбца, вам действительно нужно убедиться, что включены только цифры, а данные представляют собой правильно сформированные телефонные номера.

У вас могут быть отдельные столбцы для добавочных номеров и телефонные номера с текстом, например, приведенный мной пример «1-800-DBA-HELP».

Ранее было написано:

«С MariaDB вы можете использовать computedполе для извлечения только цифр для автодозвонщика. Также работает для MySQL 5.7».

В ответ на вопрос ОП об этом («Вы можете немного объяснить, что вы мне говорите?»), Вот объяснение.

Многие системы баз данных уже представили эту функцию. Это поля, которые по-разному известны как " computed", " virtual" или " generated", которые получены из значений в других полях. Мощность этой функции зависит от вашей РСУБД. Я знаю, что Oracle, Firebird, MariaDB и теперь MySQL 5.7 имеют их. Другие, вероятно, тоже.

Простым примером может быть наличие столбца фамилии и вычисляемого столбца, который «хранит» (помните, что они могут быть виртуальными - то есть рассчитаны на лету, или их можно физически сохранить на диске), фамилию как все столицы, тем самым делая искать проще. Таким образом, вам нужно только искать по CAPs (используя, скажем, LIKE), зная, что данные ищутся в [ computed| virtual| generated] поле написано заглавными буквами.

Концепция MySQL 5.7 объясняется здесь и здесь . Это было в MariaDB немного дольше, и концепция также объясняется здесь . Некоторые возможные варианты использования предлагаются здесь , но вы ограничены только вашим воображением. Их можно рассматривать как удобную (и менее подверженную ошибкам) ​​замену триггеров.

Для вашего конкретного случая использования вы можете получить набираемый номер из текстового поля «+» -> «00» (или любого другого кода для вашего международного телефонного номера). Просто мысль.

Хм. Телефонные номера состоят из номеров. Использование varchar позволяет пользователю сохранять любой тип форматирования, с (или нет, с - или., И это быстро создает беспорядок с вашими данными. Формат # телефона зависит от "страны", маску следует привязать к стране. Расширение является расширением и является необязательным, поэтому его следует хранить в «поле расширения». (также int). Для 1-800-DBA-HELP я бы преобразовал это на лету и сохранил фактическое число. Если вам это действительно нужно Удобный для чтения телефон #, храните его в отдельном поле varchar.

Я обычно храню номера телефонов в простом тексте . Форматирование и отображение оставьте его клиентскому коду.

Здесь больше, чем, как вы храните? то, что вы собираетесь делать с этим номером телефона, действительно важно.

Если ваш бизнес хочет выполнять исходящие звонки из вашей системы, приложение будет извлекать только номера. Если ваш бизнес хочет совершать международные звонки , храните код страны и код города в отдельных столбцах.

Если ваш бизнес хочет для отчетности , приложение будет форматировать и отображать с расширением и номерами отдельно.

Насколько я понимаю, разработка универсальной модели данных для номера телефона не очень хорошая идея. Каждая страна имеет разные номера, добавочные номера и код города, кроме кода страны. Кроме того, я узнал, что в некоторых странах отсутствует код города.

Это может не ответить на ваш вопрос, но поможет расширить наше понимание. Спасибо.