Столбцы телефонных номеров в базе данных - PullRequest
19 голосов
/ 14 ноября 2008

В последних 3 компаниях, в которых я работал, столбцы номеров телефонов имеют тип varchar (n). Причина в том, что они могут захотеть хранить расширения (доб. 333). Но в любом случае символы «-» удаляются при вставке и обновлении. Я не понимаю, почему символы «.ext» можно хранить, а не «-». Кто-нибудь еще видел это и какое объяснение вы можете придумать, чтобы сделать это таким образом? Если все, что вы хотите сохранить, это числа, то не лучше ли вам использовать поле int? И наоборот, если вы хотите сохранить число в виде строки / varchar, то почему бы не сохранить все символы и не беспокоиться о форматировании на дисплее и очистке при записи?

Мне также интересно узнать о других способах хранения телефонных номеров в других местах.

Ответы [ 10 ]

30 голосов
/ 14 ноября 2008

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

12 голосов
/ 14 ноября 2008

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

Например: 01202 8765432

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

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

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

3 голосов
/ 14 ноября 2008

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

1 голос
/ 30 июля 2011

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

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

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

1 голос
/ 14 ноября 2008

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

0 голосов
/ 13 ноября 2013

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

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

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

0 голосов
/ 14 ноября 2008

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

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

0 голосов
/ 14 ноября 2008

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

0 голосов
/ 14 ноября 2008

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

0 голосов
/ 14 ноября 2008

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

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

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

...