sql-server — Какой тип данных должен использоваться для хранения телефонных номеров в SQL Server 2005?" />

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

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

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

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

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

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

66 голосов | спросил John 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 21:57:31 +0400 2008, 21:57:31

15 ответов


0

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

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

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

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

ответил Kearns 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 22:02:48 +0400 2008, 22:02:48
0

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

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

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

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

ответил Brad Osterloo 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 22:03:29 +0400 2008, 22:03:29
0

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

ответил Joseph Bui 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 22:00:49 +0400 2008, 22:00:49
0

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

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

ответил cori 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 22:00:02 +0400 2008, 22:00:02
0

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

Алекс

ответил Alex Fort 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 22:00:33 +0400 2008, 22:00:33
0

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

ответил Joseph Daigle 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 22:02:01 +0400 2008, 22:02:01
0

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

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

ответил fjleon 3 Maypm11 2011, 20:12:23
0

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

ответил John Sheehan 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 21:59:02 +0400 2008, 21:59:02
0

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

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

ответил Iain Holder 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 21:59:44 +0400 2008, 21:59:44
0

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

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

ответил 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 22:05:57 +0400 2008, 22:05:57
0

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

ответил Magnus Johansson 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 22:09:01 +0400 2008, 22:09:01
0

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

ответил user13270 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2008 22:00:16 +0400 2008, 22:00:16
0

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

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

ответил Rob G 22 J000000Monday13 2013, 13:34:23
0

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

IE

.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string
ответил user238615 23 MaramThu, 23 Mar 2017 04:14:18 +03002017-03-23T04:14:18+03:0004 2017, 04:14:18
0

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

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

Спасибо.

ответил Jayghosh Wankar 12 PM00000050000001531 2017, 17:36:15

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132