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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Алекс

Answer 6

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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

Answer 11

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

Answer 12

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

Answer 13

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

В качестве альтернативы можно нормализовать входные данные, чтобы любое «ext» преобразулось в «x», что дает максимум 20.

Answer 14

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

ИЕ

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

Answer 15

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

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

Спасибо.