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

Question

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

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

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

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

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

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

1785 15

sql-server indexing

15 ответов:

Comments

Ничего не найдено.

Kearns · Accepted Answer · 2008-09-17 20:36:28

входит:

международные номера?

расширения?

другая информация, кроме фактического номера (например, "спросите Бобби")?

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

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

Brad Osterloo · Accepted Answer · 2008-09-17 06:09:08

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

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

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

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

Joseph Bui · Accepted Answer · 2008-09-16 21:00:49

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

cori · Accepted Answer · 2008-09-16 21:00:02

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

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

Alex Fort · Accepted Answer · 2008-09-16 21:00:33

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

Алекс

Joseph Daigle · Accepted Answer · 2008-09-16 21:02:01

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

fjleon · Accepted Answer · 2011-05-03 19:12:23

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

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

John Sheehan · Accepted Answer · 2008-09-16 20:59:02

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

Iain Holder · Accepted Answer · 2008-09-16 20:59:44

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

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

score 1 · Accepted Answer · 2008-09-16 21:05:57

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

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

Magnus Johansson · Accepted Answer · 2008-09-16 21:09:01

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

user13270 · Accepted Answer · 2011-08-15 14:18:27

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

Rob G · Accepted Answer · 2013-07-22 12:34:23

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

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

user238615 · Accepted Answer · 2018-01-31 19:33:10

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

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

Jayghosh Wankar · Accepted Answer · 2017-08-12 17:36:15

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

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

спасибо.