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

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

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

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

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

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

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

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

Алекс

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

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

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

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

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

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

Мы используем varchar (15) и обязательно index для этого поля.

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

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

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

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

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

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

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

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

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

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

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

IE

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

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

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

Спасибо.

Вместо этого используйте тип данных long .. не используйте int, потому что он допускает только целые числа от -32 768 до 32 767, но если вы используете длинный тип данных, вы можете вставлять числа от -2 147 483 648 до 2 147 483 647.