поле телефон имеет тип данных
тип данных mysql для номера телефона и адреса
Я хочу ввести номер телефона в форме, включая код страны, расширение
например, если у меня есть код страны для Канады я могу использовать +2 или 002. Что лучше для обработки?
10 ответов
ну, лично я не использую числовой тип данных для хранения телефонных номеров и другая информация.
Как вы храните номер, скажем, 001234567? Это закончится как 1234567, потеряв ведущие нули.
конечно, вы всегда можете оставить его, но это при условии, что вы точно знаете, сколько цифр должно быть.
Это не ответ на весь ваш пост,
Просто мои 2 цента
на самом деле вы можете использовать varchar для телефонного номера. Вам не нужен int, потому что вы не собираетесь выполнять арифметику на числах.
прежде чем хранить файлы, мы анализируем номер телефона, чтобы получить форматирование, которое было использовано, и которое создает маску, мы затем храним число только цифры, например
вход: (0123) 456 7890
Номер: 01234567890
Маска: (nnnn)_nnn_nnnn
теоретически это позволяет нам выполнять поиск по числовое поле, такое как получение всех телефонных номеров, которые начинаются с определенного кода области, без необходимости беспокоиться о том, как это было введено пользователями
Я обычно храню телефонные номера как BIGINT в формате E164.
E164 никогда не начинается с 0, причем первые несколько цифр являются кодом страны.
Я бы использовал varchar для телефонных номеров. таким образом, вы также можете хранить + и (), что иногда видно в номерах tel (как вы сами упомянули). и вам не придется беспокоиться об использовании всех битов в целых числах.
Я не уверен, что это хорошая идея использовать целые числа вообще. Некоторые числа могут содержать специальные символы (например, # как часть расширения), которые вы также можете обрабатывать. Поэтому я бы предложил использовать varchars.
1 телефон в char (20) = 20 байт против 8 байт bigint (или 10 против 4 байт int для местных телефонов, до 9 цифр), меньше записей может ввести блок индекса => больше блоков = > дополнительные поиски, см. этой для получения дополнительной информации (writen для Mysql, но это должно быть верно для других реляционных баз данных).
вот пример телефонных таблиц:
или с обработкой/разделение перед вставкой (2+2+4+1 = 9 байт)
также «номер телефона не является номером», на мой взгляд, относительно типа телефонных номеров. Если мы говорим о внутренней мобильной телефонной книге, то строки в порядке, как пользователь может пожелать магазин GSM хэш-коды. Если хранить E164 телефоны, bigint-лучший вариант.
посмотреть рекомендация Twilio для получения дополнительной информации о локализации телефоны.
INT (10) не означает 10-значное число, это означает целое число с шириной отображения 10 цифр. Максимальное значение для INT в MySQL-2147483647 (или 4294967295, если без знака).
вы можете использовать BIGINT вместо INT для хранения его как числового. С помощью BIGINT сохранит вам 3 байта в строке над VARCHAR (10).
хранить «страна + область + номер отдельно». Вы можете попробовать использовать VARCHAR (20), это позволяет вам хранить международные номера телефонов, если возникнет необходимость.
varchar или текст должны быть лучшими типами данных для хранения мобильных номеров, я думаю.
Какой тип данных следует использовать для хранения телефонных номеров в SQL Server 2005?
Мне нужно хранить телефонные номера в таблице. Пожалуйста, предложите какой тип данных я должен использовать? подождать. Пожалуйста, прочитайте, прежде чем вы нажмете ответ..
Это поле должно быть сильно индексировано, поскольку торговые представители могут использовать это поле для поиска (включая поиск диких символов).
на данный момент мы ожидаем, что телефонные номера будут представлены в нескольких форматах (из XML-файла). Нужно ли писать парсер для преобразования в единый формат? Там могут быть миллионы данных (с дубликатами) и я не хочу связывать ресурсы сервера (в таких действиях, как предварительная обработка слишком много) каждый раз, когда некоторые исходные данные поступают..
любые предложения приветствуются..
обновление: У меня нет контроля над источником данных. Просто структура xml-файла является стандартной. Хотелось бы свести синтаксический анализ xml к минимуму. После того, как он находится в базе данных, извлечение должно быть быстрым. Одно сумасшедшее предложение, которое происходит здесь, заключается в том, что он должен даже работать с Ajax Функция автозаполнения (так что торговые представители могут видеть соответствующие из них сразу). ОМГ!!
15 ответов:
Если все это нет, я бы использовал поле 10 символов и вычеркнул все нечисловые данные. Если первый-да, а два других-нет, я бы использовал два поля varchar(50), одно для исходного ввода и одно со всеми нечисловыми данными, полосатыми и используемыми для индексирования. Если 2 или 3-Да, я думаю, я бы сделал два поля и какой-то сумасшедший парсер, чтобы определить, что такое расширение или другие данные, и разобраться с ним соответствующим образом. Конечно, вы могли бы избежать второго столбца, сделав что-то с индексом, где он удаляет дополнительные символы при создании индекса, но я бы просто сделал второй столбец и, вероятно, сделал удаление символов с помощью триггера.
обновление: чтобы решить проблему AJAX, это может быть не так плохо, как вы думаете. Если это реально основной способ все, что делается с таблицей, сохраняет только цифры во вторичном столбце, как я уже сказал, а затем делает индекс для этого столбца кластеризованным.
мы используем varchar (15) и, конечно, индекс на этом поле.
причина в том, что международные стандарты могут поддерживать до 15 цифр
Если вы поддерживаете международные номера, я рекомендую отдельное хранение кода мировой зоны или кода страны, чтобы лучше фильтровать запросы, чтобы вы не обнаруживали себя разбором и проверкой длины полей вашего номера телефона, чтобы ограничить возвращаемый звонки в США, например
используйте CHAR (10), если вы храните только телефонные номера США. Удалите все, кроме цифр.
Я, вероятно, упускаю очевидное здесь, но не будет ли varchar достаточно долго, чтобы ваш самый длинный ожидаемый номер телефона работал хорошо?
Если Я am пропуская что-то очевидное, я бы хотел, чтобы кто-то указал на это.
Я бы использовал varchar (22). Достаточно большой, чтобы держать североамериканский номер телефона с расширением. Вы хотели бы, чтобы раздеть все неприятные ‘(‘, ‘)’, ‘-‘ символы, или просто разобрать их все в один единый формат.
SQL Server 2005 довольно хорошо оптимизирован для запросов подстроки для текста в индексированных полях varchar. В 2005 году они ввели новую статистику в сводку строк для индексных полей. Это значительно помогает при полнотекстовом поиске.
использование varchar довольно неэффективно. используйте тип money и создайте из него объявленный пользователем тип «phonenumber», а также создайте правило, разрешающее только положительные числа.
Если вы объявите его как (19,4), вы даже можете хранить 4-значное расширение и быть достаточно большим для международных номеров, и только занимает 9 байт памяти. Кроме того, индексы являются быстрыми.
nvarchar с предварительной обработкой, чтобы стандартизировать их как можно больше. Вероятно, вы захотите извлечь расширения и сохранить их в другом поле.
нормализовать данные, а затем хранить как varchar. Нормализация может быть сложной задачей.
Это должно быть одноразовое попадание. Затем, когда появляется новая запись, вы сравниваете ее с нормализованными данными. Должно быть очень быстро.
поскольку нужно учитывать многие разные форматы номеров телефонов (и, вероятно, включать такие вещи, как расширения и т. д.) это может сделать больше смысла, чтобы просто лечить ее, как и любой другой тип varchar. Если бы вы могли управлять вводом, вы могли бы использовать несколько подходов, чтобы сделать данные более полезными, но это не так.
Как только вы решите просто рассматривать его как любую другую строку, вы можете сосредоточиться на преодолении неизбежных проблем, связанных с плохими данными, таинственным телефоном формирование числа и все остальное появится. Задача будет заключаться в создании хорошей стратегии поиска данных, а не в том, как вы их храните, на мой взгляд. Это всегда сложная задача, чтобы иметь дело с большой кучей данных, которые вы не имели никакого контроля над сбором.
использовать varchar поле с ограничением по длине.
Поле телефон имеет тип данных
В Яндекс.Директе появились новые корректировки ставок
Как оптимизировать заголовок статьи для увеличения трафика
в начале было слово «+»
Chukcha, а зачем хранить +? Например, я захочу получить номера определенного оператора, LIKE для CHAR будет настолько же производителен, как и диапазон для INT?
и чистое от формата 🙂
А еще. отдельным полем код оператора
лучше всего в varchar
будет смотреться гармоничнее, нежели
Храните номера в соответствии со стандартом E.164. Символы, отличные от цифр, не нужны.
Хранить в varchar. Сами так храним.
Попробуйте для теста записать 9999999999 в поле int
unsigned int имеется в виду.
Я бы масштабируемость сразу бы заложил.
3 поля: регион, код сети, номер телефона.
Допустим расширяемость, отчеты, да многое можно будет оптимизировать потом.
И выводить проще, если в отдельных полях будет )
Друзья, объясните, когда можно использовать один KEY для двух значений? Вот у меня есть номер телефона, который разбит на FOREIGN KEY `country` и непосредственно сам номер телефона. Я не вижу смысл создавать отдельные ключи для страны и номера, могу ли я сделать один ключ? Или для выборки это не катит? Нужно будет выбирать конкретный номер телефона, то-есть, выборка за `phone`, но использовать форматирование вывода в зависимости от `country`.
Если я хочу, чтобы целый номер country + phone был уникальным, по аналогии, нужно создавать один ключ UNIQUE?
Как лучше сохранять в базу данных номера телефонов?
(Во втором случае, я догадываюсь, что можно использовать код страны, из отдельной таблицы)
varchar тяжелее int‘а
Последний вопрос:
Вы зарекнулись про ключ, действительно, лучше ли сделать его уникальным и выкинуть ID? Тогда в таблице ВЛАДЕЛЬЦЫ (например), будет связь по самому номеру, тогда будут уходить лишние байты.
Это нормально, можно так сделать? Или всё же оставить ID? Как считаете?
Телефон вводит пользователь в любом формате. С него потом убираются все знаки, стартовая 8 заменяется на код страны и он сохраняется в Int64.
Вот что-то у меня не получилось сохранить номер 0550 используя целый тип.
Хотя вряд ли есть такие номера.
Как насчёт разделителей, лучше их просто удалять?
из 8 (912) 12
будет 891212
Просто тогда мы лишаемся одной вещи.
Может пользователь хочет чтобы его номер видели как:
89-89-11-222-11
Господа, как вы все на это смотрите?
Тогда получится универсальная схема, способная показывать номера в привычном пользователям формате по маске и не захламленная спецификой межзоновых, междугородних и международных кодов.
8 900 100-00-00, 8-2 22-99-99 и 5-25-25
Тип данных для номера телефона
Помощь в написании контрольных, курсовых и дипломных работ здесь.
C# регулярное выражение для формирования номера телефона
Всем привет! Что-то никак не могу составить регулярное выражение, для удаления лишних символов.
Регулярные выражения для номера телефона с кодом
Всем привет В общем, нужно ввести номер телефона с кодом и при выводе этого номера на экран.
Поясните, что вам мешает хранить телефон в бд как текст? Да и не только в бд.
При хранении в виде числа может пару байт и сэкономите, но сложнее форматировать будет, например как 8-999-999-99-99.
Сначала подумайте над мои вопросом, потом открывайте)
Набор номера телефона для осуществления разговора через гарнитуру компьютера
Господа, доброго времени суток! Столкнулся с задачей написания программы, основной функцией.
Узнать тип номера телефона
Можно ли как то определить тип номера телефона? Например сотовый номер или.
Реализовать контроль ошибок ввода данных в поле, предназначенное для ввода номера телефона
1.Реализовать в JavaScript контроль ошибок ввода данных в поле, предназначенное для ввода номера.
Маска для даты и номера телефона
Помогите, пожалуйста. Пишу программу и возник вопрос. Есть БД в Access, там есть такие столбцы как.