Существует ли стандарт для хранения нормализованных телефонных номеров в базе данных? - PullRequest
89 голосов
/ 03 сентября 2008

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

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

where dbo.f_normalizenum(num1) = dbo.f_normalizenum(num2)

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

[Изменить]

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

Ответы [ 18 ]

1 голос
/ 03 сентября 2008

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

Удобно для пользователя: +44 (0) 181 4642542

Нормализовано: 00441814642542

1 голос
/ 03 сентября 2008

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

1 голос
/ 03 сентября 2008

Я считаю, что большинство веб-форм правильно учитывают код страны, код города, а затем оставшиеся 7 цифр, но почти всегда забывают разрешить ввод расширения. Это почти всегда заканчивает тем, что заставляет меня произносить гневные слова, так как на работе у нас нет портье, и мне нужен мой доб. # 1002 *

Мне бы пришлось проверить, но я думаю, что наша схема БД похожа. У нас есть код страны (может быть по умолчанию США, не уверен), код города, 7 цифр и расширение.

1 голос
/ 03 сентября 2008

Я думаю, что свободный текст (возможно, varchar (25)) является наиболее широко используемым стандартом. Это позволит использовать любой формат, будь то внутренний или международный.

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

0 голосов
/ 05 сентября 2008

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

0 голосов
/ 27 сентября 2011

Удобно для пользователя: +44 (0) 181 464 2542 нормализовано: 00441814642542

(0) недопустимо в международном формате. См. Стандарт ITU-T E.123.

«Нормализованный» формат не будет полезен читателям из США, поскольку они используют 011 для международного доступа.

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

Откуда у вас номера телефонов? Если вы получаете их из части телефонной сети, вы получите строку цифр, тип номера и план, например,

441234567890 тип / план 0x11 (что означает международный E.164)

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

0 голосов
/ 04 октября 2008

Я использовал 3 разных способа хранения телефонных номеров в зависимости от требований использования.

  1. Если номер хранится только для поиска человеком и не будет использоваться для поиска, он хранится в поле строкового типа в точности так, как его ввел пользователь.
  2. Если в поле будет производиться поиск, любые лишние символы, такие как +, пробелы, скобки и т. Д., Удаляются, а оставшееся число сохраняется в поле строкового типа.
  3. Наконец, если телефонный номер будет использоваться приложением для компьютера / телефона, то в этом случае его необходимо будет ввести и сохранить в качестве действительного номера телефона, используемого системой, эта опция, конечно, является труднее всего код для.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...