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

<p>мне нужно хранить номера телефонов в таблице. пожалуйста, предложите, какой тип данных я должен использовать? <strong>подождите. пожалуйста, продолжайте читать, прежде чем нажать кнопку ответа ..</strong></p><p>это поле должно быть сильно проиндексировано, поскольку торговые представители могут использовать это поле для поиска (включая поиск по диким символам).</p><p>на данный момент мы ожидаем, что телефонные номера будут иметь несколько форматов (из файла xml). должен ли я написать парсер для преобразования в единый формат? там может быть миллионы данных (с дубликатами), и я не хочу связывать ресурсы сервера (в таких действиях, как предварительная обработка слишком много) каждый раз, когда поступают некоторые исходные данные ..</p><p>любые предложения приветствуются.</p><p>обновление: <strong>у меня нет контроля над исходными данными. просто структура xml-файла является стандартной. хотелось бы свести к минимуму синтаксический анализ xml-кода. как только он находится в базе данных, поиск должен быть быстрым. одно сумасшедшее предложение примерно здесь это должно работать даже с функцией автозаполнения ajax (так, чтобы торговые представители могли сразу увидеть соответствующие). omg !!</strong></p>

<p>включает ли это:</p><ul> <li>международные номера?</li> <li>расширения?</li> <li>другая информация, кроме фактического числа (например, "попросить бобби")?</li> </ul><p>если все это не так, я бы использовал поле из 10 символов и удалил бы все нечисловые данные. если первое - "да", а два других - "нет", я бы использовал два поля varchar (50), одно для исходного ввода и одно со всеми чередующимися нечисловыми данными и используемыми для индексации. если 2 или 3 - да, я думаю, что я бы сделал два поля и какой-нибудь сумасшедший парсер, чтобы определить, что такое расширение или другие данные, и правильно с ними работать. конечно, вы можете избежать 2-го столбца, выполнив что-то с индексом, где он удаляет лишние символы при создании индекса, но я бы просто создал второй столбец и, вероятно, выполнил бы удаление символов с помощью триггера.</p><p>обновление: для решения проблемы ajax, это может быть не так плохо, как вы думаете. если это реально основной способ что-либо сделать с таблицей, сохраните только цифры во вторичном столбце, как я уже сказал, а затем сделайте индекс для этого столбца кластеризованным.</p>

<p>мы используем varchar (15) и, конечно, индексируем это поле.</p><p>причина в том, что международные стандарты могут поддерживать до 15 цифр</p><p> <a href="http://en.wikipedia.org/wiki/phone\_number">википедия - форматы телефонных номеров</a> </p><p>если вы поддерживаете международные номера, я рекомендую отдельное хранение кода зоны мира или кода страны, чтобы лучше фильтровать запросы, чтобы вы не разбирались и не проверяли длину полей вашего номера телефона, чтобы ограничить количество возвращаемых звонков в сша для пример</p>

<p>используйте char (10), если вы храните только номера телефонов сша. удалить все, кроме цифр.</p>

<p>я, наверное, здесь упускаю очевидное, но разве varchar не будет достаточно длинным, чтобы ваш самый ожидаемый номер телефона работал хорошо?</p><p>если бы я <em>я</em> упустил что-то очевидное, я был бы рад, если бы кто-то указал на это ...</p>

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

<p>использование varchar довольно неэффективно. используйте тип money и создайте из него объявленный пользователем тип phonenumber, а также создайте правило, разрешающее только положительные числа.</p><p>если вы объявите его как (19,4), вы можете даже сохранить 4-значный номер и быть достаточно большим для международных номеров, и займет всего 9 байтов. также индексы скоростные.</p>

<p>sql server 2005 довольно хорошо оптимизирован для запросов на подстроки текста в индексированных полях varchar. в 2005 году они добавили новую статистику в сводку строк для полей индекса. это значительно помогает при полнотекстовом поиске.</p>

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

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

<p>нормализуйте данные и сохраните их в виде архива. нормализация может быть сложно.</p><p>это должно быть одноразовым хитом. затем, когда появляется новая запись, вы сравниваете ее с нормализованными данными. должно быть очень быстро.</p>

<p>используйте поле <code>varchar</code> с ограничением длины.</p>

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

<p>используйте ssis для извлечения и обработки информации. таким образом, обработка xml-файлов будет отделена от sql server. при необходимости вы также можете выполнять преобразования служб ssis на отдельном сервере. храните телефонные номера в стандартном формате, используя varchar. nvarchar не понадобится, поскольку мы говорим о числах и, возможно, о нескольких других символах, таких как "+", "", "(", ")" и "-".</p>

<p>я понимаю, что этот поток старый, но стоит упомянуть о преимуществах хранения в качестве числового типа для форматирования, особенно в .net framework.</p><p>ie</p><pre><code>.defaultcellstyle.format = "(###)###-####" // will not work on a string </code></pre>

<p><strong>всегда лучше иметь отдельные таблицы для многозначных атрибутов, таких как номер телефона.</strong></p><p>поскольку у вас нет контроля над исходными данными, вы можете проанализировать данные из файла xml и преобразовать их в правильный формат, чтобы не было проблем с форматами конкретной страны, и сохранить их в отдельной таблице, чтобы - <strong>индексирование и поиск оба будут эффективными</strong>.</p><p>спасибо.</p>