Колонки номера телефона в базе данных

Ответ 1

Быстрый тест: собираетесь ли вы добавлять/вычитать/размножать/делить телефонные номера? Неа. Аналогично SSN, номера телефонов представляют собой отдельные фрагменты данных, которые могут содержать действительные числа, поэтому тип строки, вероятно, наиболее подходит.

Ответ 2

одна точка с сохранением телефонных номеров является ведущим 0.

например: 01202 8765432

в столбце int, значение 0 будет лишено, что делает телефонный номер недействительным.

Я бы рискнул предположить, что - быть замененным на пробелы, потому что они на самом деле ничего не значат

например: 123-456-789 = 123 456 789 = 123456789

Ответ 3

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

Ответ 4

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

Ответ 5

Еще одна причина, по которой я могу думать о том, чтобы не хранить телефонные номера как "числа", а как строки символов, - это достаточно часто часть стека программного обеспечения, которую вы использовали бы для доступа к базе данных (PHP, я смотрю на вас) не будет поддерживать достаточно большие целые числа (изначально), чтобы иметь возможность хранить некоторые из более длинных и/или экзотических телефонных номеров.

Наибольшее число, которое 32-битные могут переносить без знака, равно 4294967295. Это не сработало бы для всего русского номера мобильного телефона, например, номер 4959261234.

Таким образом, у вас есть лишнее неудобство в поиске способа переноса данных с номерами более 32 бит. Несмотря на то, что базы данных долго поддерживали очень большие целые числа, вам нужна только одна плохая ссылка в цепочке для showstopper. Как и PHP, снова.

Ответ 6

Удаление некоторых символов и разрешение другим может иметь влияние, если таблица базы данных собирается управлять другой системой, например. IP-телефония. В зависимости от задействованных систем может быть законным иметь и т.д .333 в качестве суффикса, тогда как разработчики, возможно, не учли "-" в строке (и да, я угадываю здесь...)

Как для хранения как varchar, а не int, это просто простой здравый смысл для меня. Как упоминалось ранее, ведущие нули могут быть удалены в поле int, запрос в поле int может выполнять неявные математические функции (что также может объяснять удаление "-" из текста, вы не хотите вводить 555-1234 и иметь он хранится как -679?)

Короче говоря, я не знаю точных рассуждений, но могу вывести некоторые возможности.

Ответ 7

Я бы предпочел сохранить цифры в виде строки и добавить различные "()" и "-" в свой код дисплея. С международными номерами становится все труднее. Мы справляемся с этим, имея различные "интернациональные" форматы отображения в зависимости от страны.

Ответ 8

Что мне нравится делать, если я знаю, что номера телефонов будут находиться в определенном регионе, например в Северной Америке, это изменить запись на 4 поля. 3 для кода области, 3 для префикса, 3 для строки и, возможно, 5 для расширения. Затем я вставляю их как 1 поле с '-' и, возможно, 'e' для обозначения расширения. Любой поиск курса также должен следовать одному и тому же процессу. Это гарантирует, что я получаю более регулярные данные и даже позволяю использовать номер для фактического телефонного звонка, после удаления и расширения. Я также могу легко вернуться к оригинальным 4 полям.

Ответ 9

Хороший материал! Похоже, что главное, что форматирование номера телефона фактически не является частью данных, а является аспектом страны-источника. Тем не менее, сохраняя часть расширения числа как есть, можно сломать модель ветки форматирования от данных. Я сомневаюсь, что все страны используют один и тот же синтаксис/формат для описания расширения. Кроме того, если интеграция с телефонной системой является (возможным) требованием, возможно, лучше сохранить расширение отдельно и построить сообщение, как ожидается. Но Марк также подчеркивает, что если вы согласны, то, вероятно, не имеет значения, как вы его сохраняете, так как вы можете запросить и обработать его последовательно.

Спасибо Эрик за ссылку на другой вопрос.

Ответ 10

Когда автоматическая телефонная система использует поле для совершения телефонного звонка, он не может определить, какие символы он должен использовать и который он должен игнорировать при наборе номера. Человек может видеть символ "(" или ")" или "-" и знать, что они считаются разделителями, разделяющими код зоны, npa и nxx номера телефона. Помните, что каждый символ представляет собой двоичный шаблон, который, если только он не запрограммирован для игнорирования, будет введен автоматическим номеронабирателем. Чтобы учесть это, лучше сохранить эквивалент только символов, которые пользователь нажимал на телефонную трубку, и даже лучше, чтобы отдельные значения сохранялись в отдельных столбцах, чтобы дозвон мог использовать отдельные поля без необходимости синтаксического анализа строки.

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

В комментариях об использовании строкового или целочисленного типа данных, как указано выше, это правильный способ хранения телефонных номеров на основе различий между странами. Для этого существует важное предостережение, хотя в то время как агрегирование статистических данных для отчетности (т.е. СУММ количества строк и вызовов) МНОГО медленнее для подсчета, чем целые числа. Чтобы учесть это, важно добавить целое число как столбец идентификатора, который можно использовать для подсчета вместо поля типа varchar или char.