Номер телефона это какой тип поля - Каталог телефонных номеров компаний России и СНГ

тип данных mysql для номера телефона и адреса

Если tel_number больше 15 бит, какой тип данных я могу использовать, мне лучше использовать Bigint(20) ?

например, если у меня есть код страны для Канады я могу использовать +2 или 002. Что лучше для обработки?

Спасибо за совет.

10 ответов

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

Как вы храните номер, скажем, 001234567? Это закончится как 1234567, потеряв ведущие нули.

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

Это не ответ на весь ваш пост,
Просто мои 2 цента

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

храните их как два поля для телефонных номеров — » номер «и» маска » как TinyText типы которые не нуждаются в более чем 255 пунктов.

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

вход: (0123) 456 7890
Номер: 01234567890
Маска: (nnnn)_nnn_nnnn

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

Я обычно храню телефонные номера как BIGINT в формате E164.

E164 никогда не начинается с 0, причем первые несколько цифр являются кодом страны.

etc. будет храниться как 441234567890 .

Я бы использовал varchar для телефонных номеров. таким образом, вы также можете хранить + и (), что иногда видно в номерах tel (как вы сами упомянули). и вам не придется беспокоиться об использовании всех битов в целых числах.

Я не уверен, что это хорошая идея использовать целые числа вообще. Некоторые числа могут содержать специальные символы (например, # как часть расширения), которые вы также можете обрабатывать. Поэтому я бы предложил использовать varchars.

если хранение менее 1 млн записей, а высокая производительность не является проблемой для varchar (20) / char(20) в противном случае я обнаружил, что для хранения даже 100 миллионов глобальных бизнес-телефонов или личных телефонов int лучше всего. Причина: меньший ключ — > более высокая скорость чтения / записи, также форматирование может допускать дубликаты.

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 Мобильный телефон — char или int?

В каком типе поля SQL лучше хранить мобильный телефон — char или int?

в начале было слово «+»

Chukcha, а зачем хранить +? Например, я захочу получить номера определенного оператора, LIKE для CHAR будет настолько же производителен, как и диапазон для INT?

Ок. Храните в двух полях — форматированное по вашему желанию

и чистое от формата 🙂

Если хотите использовать для поиска — char без формата номера, для быстрого доступа — отформатировнный

А еще. отдельным полем код оператора

лучше всего в varchar

будет смотреться гармоничнее, нежели

да и пользоваться тоже удобнее

Храните номера в соответствии со стандартом E.164. Символы, отличные от цифр, не нужны.

Хранить в varchar. Сами так храним.

Попробуйте для теста записать 9999999999 в поле int

unsigned int имеется в виду.

Я бы масштабируемость сразу бы заложил.

3 поля: регион, код сети, номер телефона.

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

И выводить проще, если в отдельных полях будет )

Друзья, объясните, когда можно использовать один KEY для двух значений? Вот у меня есть номер телефона, который разбит на FOREIGN KEY `country` и непосредственно сам номер телефона. Я не вижу смысл создавать отдельные ключи для страны и номера, могу ли я сделать один ключ? Или для выборки это не катит? Нужно будет выбирать конкретный номер телефона, то-есть, выборка за `phone`, но использовать форматирование вывода в зависимости от `country`.

Если я хочу, чтобы целый номер country + phone был уникальным, по аналогии, нужно создавать один ключ UNIQUE?

Какой тип данных лучше всего подходит для телефонного номера в MySQL и каким должно быть сопоставление типов Java для него?

Я использую MySQL с шаблоном Spring JDBC для своего веб-приложения. Мне нужно сохранить номер телефона только цифрами (10). Я немного смущен типом данных с использованием типа данных.

Какой тип данных для него предпочтительнее в MySQL?
Каким должен быть тип данных Java в классах Bean (POJO) для этого?
Как я могу проверить этот тип данных с помощью проверок / ограничений javax для длины, а также разрешенной только цифры?

Строки и VARCHAR.

Не пытайтесь сохранять телефонные номера как настоящие. это испортит форматирование, удалит предыдущие 0 и другие нежелательные вещи.

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

Прежде чем пытаться вводить какие-либо ограничения длины, проверки или маски (например, XXX-XXXX-XX), узнайте о мире в целом и о том, как различаются их длина и форматирование номеров.

В телефонных номерах могут использоваться нечисловые символы. Яркий пример + — замена 00 в начале международного номера.

Источник

I need to store phone numbers in a table. Please suggest which datatype should I use?
Wait. Please read on before you hit reply..

This field needs to be indexed heavily as Sales Reps can use this field for searching (including wild character search).

As of now, we are expecting phone numbers to come in a number of formats (from an XML file). Do I have to write a parser to convert to a uniform format? There could be millions of data (with duplicates) and I dont want to tie up the server resources (in activities like preprocessing too much) every time some source data comes through..

Any suggestions are welcome..

Update: I have no control over source data. Just that the structure of xml file is standard. Would like to keep the xml parsing to a minimum.
Once it is in database, retrieval should be quick. One crazy suggestion going on around here is that it should even work with Ajax AutoComplete feature (so Sales Reps can see the matching ones immediately). OMG!!

asked Sep 16, 2008 at 17:57

JohnJohn

9631 gold badge6 silver badges8 bronze badges

Does this include:

International numbers?
Extensions?
Other information besides the actual number (like «ask for bobby»)?

If all of these are no, I would use a 10 char field and strip out all non-numeric data. If the first is a yes and the other two are no, I’d use two varchar(50) fields, one for the original input and one with all non-numeric data striped and used for indexing. If 2 or 3 are yes, I think I’d do two fields and some kind of crazy parser to determine what is extension or other data and deal with it appropriately. Of course you could avoid the 2nd column by doing something with the index where it strips out the extra characters when creating the index, but I’d just make a second column and probably do the stripping of characters with a trigger.

Update: to address the AJAX issue, it may not be as bad as you think. If this is realistically the main way anything is done to the table, store only the digits in a secondary column as I said, and then make the index for that column the clustered one.

answered Sep 16, 2008 at 18:02

KearnsKearns

1,0797 silver badges10 bronze badges

We use varchar(15) and certainly index on that field.

The reason being is that International standards can support up to 15 digits

Wikipedia — Telephone Number Formats

If you do support International numbers, I recommend the separate storage of a World Zone Code or Country Code to better filter queries by so that you do not find yourself parsing and checking the length of your phone number fields to limit the returned calls to USA for example

answered Sep 16, 2008 at 18:03

Use CHAR(10) if you are storing US Phone numbers only. Remove everything but the digits.

answered Sep 16, 2008 at 18:00

Joseph BuiJoseph Bui

1,69116 silver badges22 bronze badges

I’m probably missing the obvious here, but wouldn’t a varchar just long enough for your longest expected phone number work well?

If I am missing something obvious, I’d love it if someone would point it out…

answered Sep 16, 2008 at 18:00

coricori

8,5967 gold badges45 silver badges80 bronze badges

I would use a varchar(22). Big enough to hold a north american phone number with extension. You would want to strip out all the nasty ‘(‘, ‘)’, ‘-‘ characters, or just parse them all into one uniform format.

Alex

answered Sep 16, 2008 at 18:00

Alex FortAlex Fort

18.2k5 gold badges42 silver badges51 bronze badges

nvarchar with preprocessing to standardize them as much as possible. You’ll probably want to extract extensions and store them in another field.

answered Sep 16, 2008 at 17:59

John SheehanJohn Sheehan

76.8k30 gold badges159 silver badges194 bronze badges

SQL Server 2005 is pretty well optimized for substring queries for text in indexed varchar fields. For 2005 they introduced new statistics to the string summary for index fields. This helps significantly with full text searching.

answered Sep 16, 2008 at 18:02

Joseph DaigleJoseph Daigle

47.2k10 gold badges50 silver badges73 bronze badges

using varchar is pretty inefficient. use the money type and create a user declared type «phonenumber» out of it, and create a rule to only allow positive numbers.

if you declare it as (19,4) you can even store a 4 digit extension and be big enough for international numbers, and only takes 9 bytes of storage. Also, indexes are speedy.

answered May 3, 2011 at 16:12

fjleonfjleon

3413 silver badges10 bronze badges

Normalise the data then store as a varchar. Normalising could be tricky.

That should be a one-time hit. Then as a new record comes in, you’re comparing it to normalised data. Should be very fast.

answered Sep 16, 2008 at 17:59

Iain HolderIain Holder

14.1k10 gold badges65 silver badges86 bronze badges

Since you need to accommodate many different phone number formats (and probably include things like extensions etc.) it may make the most sense to just treat it as you would any other varchar. If you could control the input, you could take a number of approaches to make the data more useful, but it doesn’t sound that way.

Once you decide to simply treat it as any other string, you can focus on overcoming the inevitable issues regarding bad data, mysterious phone number formating and whatever else will pop up. The challenge will be in building a good search strategy for the data and not how you store it in my opinion. It’s always a difficult task having to deal with a large pile of data which you had no control over collecting.

answered Sep 16, 2008 at 18:05

unicorn.ninjaunicorn.ninja

Use SSIS to extract and process the information. That way you will have the processing of the XML files separated from SQL Server. You can also do the SSIS transformations on a separate server if needed. Store the phone numbers in a standard format using VARCHAR. NVARCHAR would be unnecessary since we are talking about numbers and maybe a couple of other chars, like ‘+’, ‘ ‘, ‘(‘, ‘)’ and ‘-‘.

answered Sep 16, 2008 at 18:09

Magnus JohanssonMagnus Johansson

27.8k19 gold badges104 silver badges164 bronze badges

Use a varchar field with a length restriction.

agf

167k42 gold badges283 silver badges234 bronze badges

answered Sep 16, 2008 at 18:00

It is fairly common to use an «x» or «ext» to indicate extensions, so allow 15 characters (for full international support) plus 3 (for «ext») plus 4 (for the extension itself) giving a total of 22 characters. That should keep you safe.

Alternatively, normalise on input so any «ext» gets translated to «x», giving a maximum of 20.

answered Jul 22, 2013 at 9:34

Rob GRob G

744 bronze badges

It is always better to have separate tables for multi valued attributes like phone number.

As you have no control on source data so, you can parse the data from XML file and convert it into the proper format so that there will not be any issue with formats of a particular country and store it in a separate table so that indexing and retrieval both will be efficient.

Thank you.

answered Aug 12, 2017 at 14:36

I realize this thread is old, but it’s worth mentioning an advantage of storing as a numeric type for formatting purposes, specifically in .NET framework.

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

ΩmegaMan

28.4k10 gold badges98 silver badges117 bronze badges

answered Mar 23, 2017 at 1:14

Mr. TripodiMr. Tripodi

8091 gold badge6 silver badges7 bronze badges

Use data type long instead.. dont use int because it only allows whole numbers between -32,768 and 32,767 but if you use long data type you can insert numbers between -2,147,483,648 and 2,147,483,647.

answered Apr 2, 2020 at 20:31

For most cases, it will be done with bigint

Just save unformatted phone numbers like: 19876543210, 02125551212, etc.

Check the topic about bigint vs varchar

answered Dec 19, 2022 at 15:11

job.js.orgjob.js.org

2,4272 gold badges18 silver badges29 bronze badges

Источник

I need to store phone numbers in a table. Please suggest which datatype should I use?
Wait. Please read on before you hit reply..

This field needs to be indexed heavily as Sales Reps can use this field for searching (including wild character search).

Any suggestions are welcome..

asked Sep 16, 2008 at 17:57

JohnJohn

9631 gold badge6 silver badges8 bronze badges

Does this include:

International numbers?
Extensions?
Other information besides the actual number (like «ask for bobby»)?

answered Sep 16, 2008 at 18:02

KearnsKearns

1,0797 silver badges10 bronze badges

We use varchar(15) and certainly index on that field.

The reason being is that International standards can support up to 15 digits

Wikipedia — Telephone Number Formats

answered Sep 16, 2008 at 18:03

Use CHAR(10) if you are storing US Phone numbers only. Remove everything but the digits.

answered Sep 16, 2008 at 18:00

Joseph BuiJoseph Bui

1,69116 silver badges22 bronze badges

I’m probably missing the obvious here, but wouldn’t a varchar just long enough for your longest expected phone number work well?

If I am missing something obvious, I’d love it if someone would point it out…

answered Sep 16, 2008 at 18:00

coricori

8,5967 gold badges45 silver badges80 bronze badges

Alex

answered Sep 16, 2008 at 18:00

Alex FortAlex Fort

18.2k5 gold badges42 silver badges51 bronze badges

nvarchar with preprocessing to standardize them as much as possible. You’ll probably want to extract extensions and store them in another field.

answered Sep 16, 2008 at 17:59

John SheehanJohn Sheehan

76.8k30 gold badges159 silver badges194 bronze badges

answered Sep 16, 2008 at 18:02

Joseph DaigleJoseph Daigle

47.2k10 gold badges50 silver badges73 bronze badges

using varchar is pretty inefficient. use the money type and create a user declared type «phonenumber» out of it, and create a rule to only allow positive numbers.

if you declare it as (19,4) you can even store a 4 digit extension and be big enough for international numbers, and only takes 9 bytes of storage. Also, indexes are speedy.

answered May 3, 2011 at 16:12

fjleonfjleon

3413 silver badges10 bronze badges

Normalise the data then store as a varchar. Normalising could be tricky.

That should be a one-time hit. Then as a new record comes in, you’re comparing it to normalised data. Should be very fast.

answered Sep 16, 2008 at 17:59

Iain HolderIain Holder

14.1k10 gold badges65 silver badges86 bronze badges

answered Sep 16, 2008 at 18:05

unicorn.ninjaunicorn.ninja

answered Sep 16, 2008 at 18:09

Magnus JohanssonMagnus Johansson

27.8k19 gold badges104 silver badges164 bronze badges

Use a varchar field with a length restriction.

agf

167k42 gold badges283 silver badges234 bronze badges

answered Sep 16, 2008 at 18:00

Alternatively, normalise on input so any «ext» gets translated to «x», giving a maximum of 20.

answered Jul 22, 2013 at 9:34

Rob GRob G

744 bronze badges

It is always better to have separate tables for multi valued attributes like phone number.

Thank you.

answered Aug 12, 2017 at 14:36

I realize this thread is old, but it’s worth mentioning an advantage of storing as a numeric type for formatting purposes, specifically in .NET framework.

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

ΩmegaMan

28.4k10 gold badges98 silver badges117 bronze badges

answered Mar 23, 2017 at 1:14

Mr. TripodiMr. Tripodi

8091 gold badge6 silver badges7 bronze badges

answered Apr 2, 2020 at 20:31

For most cases, it will be done with bigint

Just save unformatted phone numbers like: 19876543210, 02125551212, etc.

Check the topic about bigint vs varchar

answered Dec 19, 2022 at 15:11

job.js.orgjob.js.org

2,4272 gold badges18 silver badges29 bronze badges

Источник

If storing less then 1 mil records, and high performance is not an issue go for varchar(20)/char(20) otherwise I’ve found that for storing even 100 milion global business phones or personal phones, int is best. Reason : smaller key -> higher read/write speed, also formatting can allow for duplicates.

1 phone in char(20) = 20 bytes vs 8 bytes bigint (or 10 vs 4 bytes int for local phones, up to 9 digits) , less entries can enter the index block => more blocks => more searches, see this for more info (writen for Mysql but it should be true for other Relational Databases).

Here is an example of phone tables:

CREATE TABLE `phoneNrs` (   
    `internationalTelNr` bigint(20) unsigned NOT NULL COMMENT 'full number, no leading 00 or +, up to 19 digits, E164 format',
    `format` varchar(40) NOT NULL COMMENT 'ex: (+NN) NNN NNN NNN, optional',
    PRIMARY KEY (`internationalTelNr`)
    )
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin

or with processing/splitting before insert (2+2+4+1 = 9 bytes)

CREATE TABLE `phoneNrs` (   
    `countryPrefix` SMALLINT unsigned NOT NULL COMMENT 'countryCode with no leading 00 or +, up to 4 digits',
    `countyPrefix` SMALLINT unsigned NOT NULL COMMENT 'countyCode with no leading 0, could be missing for short number format, up to 4 digits',
    `localTelNr` int unsigned NOT NULL COMMENT 'local number, up to 9 digits',
    `localLeadingZeros` tinyint unsigned NOT NULL COMMENT 'used to reconstruct leading 0, IF(localLeadingZeros>0;LPAD(localTelNr,localLeadingZeros+LENGTH(localTelNr),'0');localTelNr)',
    PRIMARY KEY (`countryPrefix`,`countyPrefix`,`localLeadingZeros`,`localTelNr`)  -- ordered for fast inserts
) 
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin
;

Also «the phone number is not a number», in my opinion is relative to the type of phone numbers. If we’re talking of an internal mobile phoneBook, then strings are fine, as the user may wish to store GSM Hash Codes. If storing E164 phones, bigint is the best option.

Источник

Я хочу ввести номер телефона в форме, включая код страны, расширение

create table if not exists employee(    `   
      country_code_tel   int(11),
      tel_number         int(10),
      extension          int(10),
      mobile             bigint(20)
);

Если tel_number больше 15 бит, какой тип данных я могу использовать, мне лучше использовать Bigint(20)?

create table address(
      address           varchar(255),  
      city              varchar(255),
      country           varchar(255),
      post_code         int(11)
);

например, если у меня есть код страны для Канады я могу использовать +2 или 002. Что лучше для обработки?

Спасибо за совет.

10 ответов

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

Как вы храните номер, скажем, 001234567? Это закончится как 1234567, потеряв ведущие нули.

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

Это не ответ на весь ваш пост,
Просто мои 2 цента

автор: Vincent Ramdhanie

храните их как два поля для телефонных номеров — » номер «и» маска » как TinyText типы которые не нуждаются в более чем 255 пунктов.

вход: (0123) 456 7890
Номер:01234567890
Маска:(nnnn)_nnn_nnnn

Я обычно храню телефонные номера как BIGINT в формате E164.

E164 никогда не начинается с 0, причем первые несколько цифр являются кодом страны.

+441234567890
+44 (0)1234 567890
01234 567890

etc. будет храниться как 441234567890.

1 телефон в char (20) = 20 байт против 8 байт bigint (или 10 против 4 байт int для местных телефонов, до 9 цифр), меньше записей может ввести блок индекса => больше блоков = > дополнительные поиски, см. этой для получения дополнительной информации (writen для Mysql, но это должно быть верно для других реляционных баз данных).

вот пример телефонных таблиц:

CREATE TABLE `phoneNrs` (   
    `internationalTelNr` bigint(20) unsigned NOT NULL COMMENT 'full number, no leading 00 or +, up to 19 digits, E164 format',
    `format` varchar(40) NOT NULL COMMENT 'ex: (+NN) NNN NNN NNN, optional',
    PRIMARY KEY (`internationalTelNr`)
    )
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin

или с обработкой/разделение перед вставкой (2+2+4+1 = 9 байт)

CREATE TABLE `phoneNrs` (   
    `countryPrefix` SMALLINT unsigned NOT NULL COMMENT 'countryCode with no leading 00 or +, up to 4 digits',
    `countyPrefix` SMALLINT unsigned NOT NULL COMMENT 'countyCode with no leading 0, could be missing for short number format, up to 4 digits',
    `localTelNr` int unsigned NOT NULL COMMENT 'local number, up to 9 digits',
    `localLeadingZeros` tinyint unsigned NOT NULL COMMENT 'used to reconstruct leading 0, IF(localLeadingZeros>0;LPAD(localTelNr,localLeadingZeros+LENGTH(localTelNr),'0');localTelNr)',
    PRIMARY KEY (`countryPrefix`,`countyPrefix`,`localLeadingZeros`,`localTelNr`)  -- ordered for fast inserts
) 
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin
;

вы можете использовать BIGINT вместо INT для хранения его как числового. С помощью
BIGINT сохранит вам 3 байта в строке над VARCHAR (10).

varchar или текст должны быть лучшими типами данных для хранения мобильных номеров, я думаю.

Источник

На сайте с 29.05.2008

Offline

195

12 сентября 2013, 19:12

13297

Здравствуйте.

В каком типе поля SQL лучше хранить мобильный телефон — char или int?

SQL Мобильный телефон — char или int?

Всего проголосовало: 15

На сайте с 04.02.2005

Offline

274

12 сентября 2013, 19:17

char

в начале было слово «+»

На сайте с 29.05.2008

Offline

195

12 сентября 2013, 19:18

На сайте с 04.02.2005

Offline

274

12 сентября 2013, 19:30

Ок. Храните в двух полях — форматированное по вашему желанию

и чистое от формата

Если хотите использовать для поиска — char без формата номера, для быстрого доступа — отформатировнный

А еще… отдельным полем код оператора

siv1987

На сайте с 02.04.2009

Offline

427

12 сентября 2013, 19:34

лучше всего в varchar

На сайте с 09.12.2005

Offline

386

13 сентября 2013, 00:07

ortegas:
Chukcha, а зачем хранить +? Например, я захочу получить номера определенного оператора, LIKE для CHAR будет настолько же производителен, как и диапазон для INT?

мне кажется

num like ‘38095_______’

будет смотреться гармоничнее, нежели

num >= 380950000000 and num <= 380959999999

да и пользоваться тоже удобнее

На сайте с 01.05.2010

Offline

644

13 сентября 2013, 04:03

int.

Храните номера в соответствии со стандартом E.164. Символы, отличные от цифр, не нужны.

На сайте с 17.08.2010

Offline

13 сентября 2013, 08:06

Хранить в varchar. Сами так храним.

Попробуйте для теста записать 9999999999 в поле int

На сайте с 01.05.2010

Offline

644

13 сентября 2013, 08:15

unsigned int имеется в виду.

На сайте с 17.08.2010

Offline

334

13 сентября 2013, 08:34

Я бы масштабируемость сразу бы заложил….

3 поля: регион, код сети, номер телефона.

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

И выводить проще, если в отдельных полях будет )

На сайте с 29.05.2008

Offline

195

13 сентября 2013, 16:55

#10

Если я хочу, чтобы целый номер country + phone был уникальным, по аналогии, нужно создавать один ключ UNIQUE?

Источник

Значение `tel`

Синтаксис

Описание

Тип tel (от англ. «telephone» ‒ «телефон») создаёт поле ввода телефонного номера.

Внешний вид

Примечание

HTML спецификация не устанавливает определённый синтаксис телефонного номера для данного поля (в отличие от «url» и «email» полей). Это сделано намеренно, так как на практике, поля телефонных номеров, как правило, имеют свободную форму, потому что существует большое разнообразие допустимых телефонных номеров. (Установить необходимый синтаксис телефонного номера можно с помощью атрибута «pattern».)

Поддержка браузерами

Спецификация

Сопутствующие атрибуты

autocomplete

Автозаполнение значения поля телефона.

autofocus

Автоматческая фокусировка на телефонном поле после полной загрузки страницы.

disabled

Блокировка поля телефона.

disabled="disabled"

form

Присоединение телефонного поле к форме.

list

Создание списка рекомендованных вариантов телефонных номеров.

maxlength

Задаёт максимально-допустимое количество вводимых символов.

minlength

Задаёт минимально-допустимое количество вводимых символов.

name

Присваивает имя телефонному полю.

pattern

Устанавливает критерий/шаблон ввода.

placeholder

Указывает текст-подсказку для пустого поля.

placeholder="Текст-подсказка"

readonly

Указывает, что поле телефона доступно только для чтения (изменение/редактирование запрещено).

required

Указывает, что поле телефона обязательно для заполнения.

size

Задаёт ширину телефонного поля по количеству вводимых символов.

size="10"

value

Указывает значение телефонного поля (отправляется на сервер или используется скриптами).

Примечание: Данный атрибут должен иметь значение, которое не содержит символов «LF» ПЕРЕВОД СТРОКИ [U+000A] или «CR» ВОЗВРАТ КАРЕТКИ [U+000D].

value="+7 (900) 123-45-67"

Глобальные атрибуты

accesskey, class, contenteditable, data-*, dir, draggable, dropzone, hidden, id, inert, lang, spellcheck, style, tabindex, title, translate, xml:lang

Пример использования

<!DOCTYPE html>
<html>
<head>
<meta charset=«utf-8»>
<title>Значение tel (input-type)</title>
</head>
<body>
<h1>Пример с полем ввода телефонного номера «type=tel»</h1>
<form action=«/examples/php-scripts/telephone.php» method=«post»>
<fieldset> <legend>Введите ваш номер телефона</legend>
<p><input type=«tel» name=«phone_number» list=«tel-list» placeholder=«+7 (900) 123-45-67» pattern=«+7s?[(]{0,1}9[0-9]{2}[)]{0,1}s?d{3}[-]{0,1}d{2}[-]{0,1}d{2}»></p>
<datalist id=«tel-list»>
<option value=«+7 (900) 123-45-67» label=«Телефонный номер №1»>
<option value=«+7 (900) 123-45-68» label=«Телефонный номер №2»>
</datalist>
</fieldset>
<p><input type=«reset»> <input type=«submit»></p>
</form>
</body>
</html>

Значение tel (input-type)

Источник

Если хранить менее 1 млн записей, а высокая производительность — это не проблема для varchar (20)/ char (20), в противном случае я обнаружил, что для хранения даже 100 миллионов глобальных телефонных телефонов или персональных телефонов int лучший. Причина: меньший ключ → более высокая скорость чтения/записи, а также форматирование может допускать дубликаты.

1 телефон в char (20) = 20 байт по сравнению с 8 байтами bigint (или 10 vs 4 байта int для локальных телефонов, до 9 цифр), меньше записей можно ввести индексный блок = > больше blocks = > больше запросов, см. this для получения дополнительной информации (writen для Mysql, но это должно быть верно для других реляционных баз данных).

Вот пример телефонных таблиц:

CREATE TABLE `phoneNrs` (   
    `internationalTelNr` bigint(20) unsigned NOT NULL COMMENT 'full number, no leading 00 or +, up to 19 digits, E164 format',
    `format` varchar(40) NOT NULL COMMENT 'ex: (+NN) NNN NNN NNN, optional',
    PRIMARY KEY (`internationalTelNr`)
    )
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin

или с обработкой/разбиением перед вставкой (2 + 2 + 4 + 1 = 9 байтов)

CREATE TABLE `phoneNrs` (   
    `countryPrefix` SMALLINT unsigned NOT NULL COMMENT 'countryCode with no leading 00 or +, up to 4 digits',
    `countyPrefix` SMALLINT unsigned NOT NULL COMMENT 'countyCode with no leading 0, could be missing for short number format, up to 4 digits',
    `localTelNr` int unsigned NOT NULL COMMENT 'local number, up to 9 digits',
    `localLeadingZeros` tinyint unsigned NOT NULL COMMENT 'used to reconstruct leading 0, IF(localLeadingZeros>0;LPAD(localTelNr,localLeadingZeros+LENGTH(localTelNr),'0');localTelNr)',
    PRIMARY KEY (`countryPrefix`,`countyPrefix`,`localLeadingZeros`,`localTelNr`)  -- ordered for fast inserts
) 
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin
;

Также «номер телефона не является числом», на мой взгляд, относится к типу телефонных номеров. Если мы говорим о внутреннем мобильном телефоне, то строки все в порядке, так как пользователь может пожелать сохранить GSM Hash Codes. Если вы храните E164, лучше всего выбрать bigint.

Источник

Главная / Web / MySQL / Хранение номеров телефонов в Б…

Хранение номеров телефонов в БД

Хранение номеров телефонов в базе данных MySQL не такая уж тривиальная задача, как может показаться на первый взгляд. Один из первых вопросов при проектировании БД: какой тип ячейки БД использовать? Цифровое поле, например INT в MySQL не подходит для этих целей, так как номера некоторых телефонов (например мобильные номера в Украине) могут начинаться с нуля, а следовательно, если попытаться сохранить такой номер как число — ведущий ноль (нули) будут потеряны. Для хранения номеров телефонов лучше всего использовать текстовый тип столбца: CHAR.

Чтобы ускорить поиск по текстовым данным имеющим различную длину, в отдельном индексируемом цифровом столбце (TINYINT) можно хранить длину номера телефона и использовать её в условиях поиска — отсекать лишние номера при поиске. Но такая реализация базы данных нужна только при очень больших объемах телефонных номеров и в большинстве случаев её можно не использовать.

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

Код1 — это, в основном, код страны (+20 — Египет, +380 — Украина и т.д.), но некоторые первичные коды телефонов могут и не иметь привязки к стране, например: 388 — European Telephony Numbering Space (Europe-wide services); 870 — Inmarsat «SNAC» service и т.д. Поэтому называть такую колонку country_code или подобным образом логически не правильно. Помимо всего прочего один первичный код может принадлежать нескольким странам: +1 — Америка, Канада и другие; 7 — Россия, Казахстан и т.д. Подробнее о таких кодах можно прочитать тут: Географические коды телефонных номеров. Хранить данные о первичном коде телефонного номера можно и в цифровом формате, так как все такие коды не могут начинаться с нуля, но исходя из соображения, что стандарт в будущем может поменяться — безопаснее сразу хранить такую информацию в текстовом виде. Максимальное количество символов Код1 — пять.

Код2 может быть кодом города, мобильного оператора или чего-нибудь еще, соответственно mob_code, city_code не являются логичными названиями для таких данных. Следует отметить, что в некоторых странах такие коды, возможно, могут начинаться и с нуля, поэтому выбор типа данных такого столбца — очевиден. Максимальное количество символов в таком столбце, скорее всего, не будет более пяти.

Номер телефона — об этом столбце написано в начале статьи. Кол-во символов в таком номере, обычно не превышает 7 штук.

Полный номер телефона содержит в себе информацию столбцов БД MySQL Код1, Код2 и Номер телефона. Этот столбец существенно упростит проверку на дублирующиеся номера. Тип и размер данных в нем высчитывается на основании колонок Код1, Код2 и Номер телефона.

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

Вывести только 1 номер телефона для всех фирм из БД

SELECT f.firm, p.phone
FROM table_firm AS f
LEFT JOIN table_phone AS p ON (f.id = p.firm_id AND p.number = 1)

Колонка порядковый номер должна содержать последовательные номера, начинающиеся с единицы, без разрывов: 1,2,3.

Хранение номеров телефонов, зачастую, подразумевает и сопутствующую их привязку к персональной информации — ФИО, название организации и т.д., а для этого, в свою очередь во многих странах требуются специальные разрешения, регистрации баз данных и т.п.

Хранение номеров телефонов в виде хеша

Если номер телефона нужен только для подтверждения регистрации пользователя — как средство защиты от ботов и мультиаккаунтов можно использовать следующую схему. Номер хранится в открытом виде только до подтверждения регистрации. После подтверждения создается и записывается в БД взломоустойчивый хеш номера телефона, а сам номер удаляется:

Пример относительно взломоустойчивого хеша на PHP

$hash = md5(md5($phone_number).‘saltBLF@#$%^’);

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

Опубликовано: 2013/03/20

HTML-код ссылки на эту страницу:

<a href=»https://petrenco.com/mysql.php?txt=168″ target=»_blank»>Хранение номеров телефонов в БД</a>

27653

Источник

тип данных mysql для номера телефона и адреса

10 ответов

SQL Мобильный телефон — char или int?

Какой тип данных лучше всего подходит для телефонного номера в MySQL и каким должно быть сопоставление типов Java для него?

10 ответов

SQL Мобильный телефон — char или int?

Значение tel

Синтаксис

Описание

Внешний вид

Примечание

Поддержка браузерами

Спецификация

Сопутствующие атрибуты

Пример использования

Хранение номеров телефонов в БД

Хранение номеров телефонов в виде хеша

Это тоже интересно:

Значение `tel`