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

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

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

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

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

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

Ответ 1

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

Международные номера?
Расширение?
Другая информация, кроме фактического номера (например, "ask for bobby" )?

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Алекс

Ответ 4

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

Ответ 5

Мне, вероятно, не хватает очевидного здесь, но не будет ли varchar достаточно длинным, чтобы ваш длинный ожидаемый номер телефона работал хорошо?

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

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

Ответ 14

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

.DefaultCellStyle.Format = "(###)###-####" 'Will not work on a string

Ответ 15

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

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

Спасибо.