it-swarm-ru.tech

Какой тип данных следует использовать для хранения телефонных номеров в SQL Server 2005?

Мне нужно хранить номера телефонов в таблице. Пожалуйста, предложите, какой тип данных я должен использовать? Подождите. Пожалуйста, продолжайте читать, прежде чем нажать кнопку ответа ..

Это поле должно быть сильно проиндексировано, поскольку торговые представители могут использовать это поле для поиска (включая поиск по диким символам).

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

Любые предложения приветствуются.

Обновление: У меня нет контроля над исходными данными. Просто структура XML-файла является стандартной. Хотелось бы свести к минимуму синтаксический анализ XML-кода. Как только он находится в базе данных, поиск должен быть быстрым. Одно сумасшедшее предложение примерно здесь это должно работать даже с функцией автозаполнения Ajax (так, чтобы торговые представители могли сразу увидеть соответствующие). OMG !!

68
John

Включает ли это:

  • Международные номера?
  • Расширения?
  • Другая информация, кроме фактического числа (например, "попросить Бобби")?

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

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

50
Kearns

Мы используем varchar (15) и, конечно, индексируем это поле.

Причина в том, что международные стандарты могут поддерживать до 15 цифр

Википедия - Форматы телефонных номеров

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

33
Brad Osterloo

Используйте CHAR (10), если вы храните только номера телефонов США. Удалить все, кроме цифр.

4
Joseph Bui

Я, наверное, здесь упускаю очевидное, но разве varchar не будет достаточно длинным, чтобы ваш самый ожидаемый номер телефона работал хорошо?

Если бы я я упустил что-то очевидное, я был бы рад, если бы кто-то указал на это ...

3
cori

Я бы использовал varchar (22). Достаточно большой, чтобы вместить североамериканский номер телефона с добавочным номером. Вы хотели бы удалить все неприятные символы '(', ')', '-' или просто разобрать их все в один единый формат.

Alex

3
Alex Fort

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

если вы объявите его как (19,4), вы можете даже сохранить 4-значный номер и быть достаточно большим для международных номеров, и займет всего 9 байтов. Также индексы скоростные.

2
fjleon

SQL Server 2005 довольно хорошо оптимизирован для запросов на подстроки текста в индексированных полях varchar. В 2005 году они добавили новую статистику в сводку строк для полей индекса. Это значительно помогает при полнотекстовом поиске.

2
Joseph Daigle

Для обозначения расширений достаточно часто использовать "x" или "ext", поэтому допускается 15 символов (для полной международной поддержки), плюс 3 (для "ext"), плюс 4 (для самого расширения), что в сумме дает 22 символа , Это должно держать вас в безопасности.

В качестве альтернативы, нормализуйте ввод, чтобы любое "ext" переводилось в "x", давая максимум 20.

1
Rob G

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

1
John Sheehan

Нормализуйте данные и сохраните их в виде архива. Нормализация может быть сложно.

Это должно быть одноразовым хитом. Затем, когда появляется новая запись, вы сравниваете ее с нормализованными данными. Должно быть очень быстро.

1
Iain Holder

Используйте поле varchar с ограничением длины.

1
user13270

Так как вам нужно использовать много разных форматов телефонных номеров (и, возможно, включать такие вещи, как добавочные номера и т.д.), Может иметь смысл рассматривать это так же, как и любой другой varchar. Если бы вы могли контролировать ввод, вы могли бы использовать несколько подходов, чтобы сделать данные более полезными, но это не звучит так.

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

1
unicorn.ninja

Используйте SSIS для извлечения и обработки информации. Таким образом, обработка XML-файлов будет отделена от SQL Server. При необходимости вы также можете выполнять преобразования служб SSIS на отдельном сервере. Храните телефонные номера в стандартном формате, используя VARCHAR. NVARCHAR не понадобится, поскольку мы говорим о числах и, возможно, о нескольких других символах, таких как "+", "", "(", ")" и "-".

1
Magnus Johansson

Я понимаю, что этот поток старый, но стоит упомянуть о преимуществах хранения в качестве числового типа для форматирования, особенно в .NET Framework.

IE

.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string
1
Mr. Tripodi

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

Поскольку у вас нет контроля над исходными данными, вы можете проанализировать данные из файла XML и преобразовать их в правильный формат, чтобы не было проблем с форматами конкретной страны, и сохранить их в отдельной таблице, чтобы - индексирование и поиск оба будут эффективными.

Спасибо.

0
Jayghosh Wankar