Столбцы телефонных номеров в базе данных
В последних трех компаниях, в которых я работал, столбцы телефонных номеров имеют тип varchar(n). Причина в том, что они могут захотеть хранить расширения (доб. 333). Но в любом случае символы "-" удаляются при вставке и обновлении. Я не понимаю, почему символы ".ext" можно хранить, но не "-". Кто-нибудь еще видел это и какое объяснение вы можете придумать, чтобы сделать это таким образом? Если все, что вы хотите сохранить, это числа, то не лучше ли вам использовать поле int? И наоборот, если вы хотите сохранить число в виде строки /varchar, то почему бы не сохранить все символы и не беспокоиться о форматировании на дисплее и очистке при записи?
Мне также интересно узнать о других способах хранения телефонных номеров в других местах.
10 ответов
Быстрый тест: собираетесь ли вы добавлять / вычитать / умножать / делить телефонные номера? Нету. Как и в случае с номерами SSN, телефонные номера представляют собой отдельные фрагменты данных, которые могут содержать действительные номера, поэтому тип строки, вероятно, является наиболее подходящим.
Одна точка с сохранением телефонных номеров - ведущая 0.
например: 01202 8765432
в столбце int будет удален 0, что делает номер телефона недействительным.
Я бы рискнул догадаться о том, что меняются местами, потому что они на самом деле ничего не значат
например: 123-456-789 = 123 456 789 = 123456789
Лично я бы не выделил никаких символов, так как в зависимости от того, откуда взят номер телефона, это может означать разные вещи. Оставьте номер телефона в том формате, в котором он был введен, поскольку очевидно, что тот, кто его набрал, привык видеть его.
На самом деле не имеет значения, как вы храните его, если оно соответствует. Нормой является удаление символов форматирования, но вы также можете хранить код страны, код города, обмен и расширение отдельно, если вам нужно запросить эти значения. Опять же, требование заключается в том, что он является последовательным - в противном случае он запрашивает PITA.
Еще одна причина, по которой я могу думать не о том, чтобы хранить телефонные номера как "числа", а как строки символов, заключается в том, что достаточно часто часть программного стека, которую вы используете для доступа к базе данных (PHP, я смотрю на вас), не будет поддерживать достаточно большие целые числа (изначально), чтобы иметь возможность хранить некоторые из более длинных и / или экзотических телефонных номеров.
Наибольшее число, которое 32-разрядный номер может нести без знака, - 4294967295. Это не сработало бы только для любого российского номера мобильного телефона, например, номер 4959261234.
Таким образом, у вас есть дополнительное неудобство, связанное с поиском способа передачи числовых данных с разрядностью более 32 бит. Несмотря на то, что базы данных давно поддерживают очень большие целые числа, вам нужен только один плохой канал в цепочке для showtopper. Как и PHP, опять же.
Что мне нравится делать, если я знаю, что телефонные номера будут только в определенном регионе, например, в Северной Америке, это изменить запись в 4 полях. 3 для кода города, 3 для префикса, 3 для строки и, возможно, 5 для расширения. Затем я вставляю их как 1 поле с '-' и, возможно, 'e', чтобы обозначить расширение. Любой поиск, конечно, также должен следовать тому же процессу. Это гарантирует, что я получаю более регулярные данные, и даже позволяет использовать номер для фактического совершения телефонного звонка после удаления - и добавочного номера. Я также могу легко вернуться к оригинальным 4 полям.
Хорошая вещь! Кажется, что главное в том, что форматирование номера телефона на самом деле не является частью данных, а является аспектом страны-источника. Тем не менее, сохраняя часть расширения как есть, можно нарушить модель отделения форматирования от данных. Я сомневаюсь, что все страны используют один и тот же синтаксис / формат для описания расширения. Кроме того, если интеграция с телефонной системой является (возможно) требованием, то может быть лучше хранить добавочный номер отдельно и создавать сообщение, как ожидается. Но Марк также отмечает, что если вы последовательны, то, вероятно, не будет иметь значения, как вы храните его, поскольку вы также можете запрашивать и обрабатывать его последовательно.
Спасибо, Эрик, за ссылку на другой вопрос.
Я бы предпочел сохранить цифры в виде строки и добавить различные "()" и "-" в мой код дисплея. С международными номерами все сложнее. Мы справляемся с этим, используя различные "интернационализированные" форматы отображения в зависимости от страны.
Когда автоматическая телефонная система использует поле для совершения телефонного звонка, она может не определить, какие символы она должна использовать, а какие следует игнорировать при наборе номера. Человек может видеть символ "(" или ")" или "-" и знать, что они считаются разделителями, разделяющими код города, npa и nxx телефонного номера. Помните, однако, что каждый символ представляет двоичный шаблон, который, если он не запрограммирован на игнорирование, будет введен автоматическим набором номера. Чтобы учесть это, лучше хранить эквивалент только тех символов, которые пользователь нажал бы на телефонной трубке, и еще лучше, чтобы отдельные значения были сохранены в отдельных столбцах, чтобы номеронабиратель мог использовать отдельные поля, не анализируя строку.
Даже если не использовать автоматизацию набора номера, рекомендуется хранить вещи, которые не нужно обновлять в будущем. Гораздо проще добавлять символы между полями, чем удалять их из строк.
В комментарии об использовании типа данных строка против целого числа, как отмечалось выше, строки являются правильным способом хранения телефонных номеров на основе различий между странами. Здесь есть важное предостережение, заключающееся в том, что при агрегировании статистики для составления отчетов (т. Е. СУММ о количестве номеров или вызовов) символьные строки НАМНОГО медленнее, чем числа. Чтобы учесть это, важно добавить целое число в качестве столбца идентификаторов, который вы можете использовать для подсчета вместо типа данных поля varchar или char.
Удаление некоторых символов и разрешение других может оказать влияние, если таблица базы данных будет управлять другой системой, например, какой-либо IP-телефонией. В зависимости от задействованных систем может быть законным иметь в качестве суффикса etc.333, тогда как разработчики могут не учитывать "-" в строке (и да, я предполагаю, что здесь...)
Что касается хранения как varchar, а не как int, это просто здравый смысл для меня. Как упоминалось ранее, начальные нули могут быть удалены в поле int, запрос в поле int может выполнять неявные математические функции (которые также могут объяснить удаление текста "-" из текста, вы не хотите вводить 555-1234 и иметь он хранится как -679?)
Короче говоря, я не знаю точных рассуждений, но могу вывести некоторые возможности.