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

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.

Источник

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

Источник

тип данных 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 в начале международного номера.

Источник

Что это такое? Типы данных SQL необходимы для организации работы всей базы. В таблице каждый столбец обязан иметь имя и указание на информацию, которая в нем содержится. Это определяет как язык, на котором написана БД, будет взаимодействовать с наполнением таблицы.

Какие бывают? В каждой конкретной СУБД существуют свои типы данных. Более того, в некоторых системах они могут иметь одинаковое название, но разные функции, поэтому всегда важно знакомиться с документацией до начала работы.

В статье рассказывается:

Задачи типов данных в SQL
Виды типов данных SQL
Хранение типов данных SQL
Преобразование типов данных
Пройди тест и узнай, какая сфера тебе подходит:
айти, дизайн или маркетинг.

Бесплатно от Geekbrains

Для начала определим, о каких данных мы говорим? В данной статье речь пойдёт о типе данных, которые любая переменная или столбец могут хранить в MS SQL Server.

Когда мы создаём любую таблицу или переменную, мы указываем имя, а также тип данных, которые будут храниться.

Задачи типов данных в SQL

Тип данных таблицы SQL, которые будут храниться в столбце или в переменной, необходимо определять заранее. Это ограничит пользователя от возможности ввести любые неожиданные или недействительные данные.

Как наиболее эффективно использовать память? Для начала назначьте соответствующий тип данных переменной или столбцу, в котором будет выделяться тот объём, который необходим системной памяти для данных столбца SQL.

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

В качестве иллюстрации можно взять простую страницу регистрации приложения web-сайта. Мы имеем три поля ввода: Имя, Фамилия, Контактный номер.

Скачать файл

Обратите внимание, что в режиме реального времени:

поля «Имя» и «Фамилия» всегда будут буквенными;
поле «Контактный номер» всегда будет числовым.

Таким образом, «Имя» и «Фамилия» надо указать как символ, а «Контактный номер» – как целое число.

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

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

Виды типов данных SQL

Строковые типы данных

К этому типы относят имена, названия, адреса и другие данные, которые выражаются словами. Строковые типы – самые распространённые.

Независимо от типа строки, её всегда заключают в одинарные кавычки. Все строковые типы условно делятся на две группы: переменной и фиксированной длины.

Строковые типы данных

У строк с переменной длиной есть ограничение по максимальному размеру поля данной СУБД, но нет ограничений «сверху». В некоторых типах встречается «нижняя граница» – минимальное количество символов. В целом, возможны разные по длине значения, и необходимости ставить дополнительные пробелы при этом нет.

Длину строк фиксированной длины определяют заранее, на этапе определения таблицы. В качестве примера можно привести поля, хранящие номера телефонов. Для них выделяют одиннадцать символов, а остальные знаки просто не сохраняются. Если же пользователь не до конца заполнит поле, СУБД автоматически завершит строку, добавив пробелы.

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

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

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

Подборка 50+ ресурсов об IT-сфере

Только лучшие телеграм-каналы, каналы Youtube, подкасты, форумы и многое другое для того, чтобы узнавать новое про IT

ТОП 50+ сервисов и приложений от Geekbrains

Безопасные и надежные программы для работы в наши дни

Уже скачали 19611

Перечислим основные строковые типы данных:

CHAR – фиксированная длина строки. В процессе создания таблицы определяется точное значение – от 1 до 225 символов;
NCHAR – одна из разновидностей CHAR, которая поддерживает Unicode или многобайтовые символы
TEXT (она же LONG, VARCHAR или MEMO) – строки переменной длинны
NVARCHAR – подвид TEXT, которые поддерживает Unicode или многобайтовые символы

Типы данных, включающие обозначение даты и времени

То или иное обозначение времени и даты включено во всех СУБД. Они, как и числовые форматы, отличаются друг от друга степенью точности и допустимым диапазоном. Варианты:

DATE – дата;
TIME – время;
TIMESTAMP или DATETIME – дата и время;
SMALLDATETIME – дата и время с точностью до минуты.

Бывают и более точные форматы, мы привели лишь самые популярные.

Бинарные типы данных

Этот тип данных обеспечивает содержание любых данных в бинарном виде. Это может быть графика, текст, медиа или двоичный код. На самом деле, бинарные типы используют довольно редко, поскольку они плохо совместимы в формате разных СУБД. И всё же порой они упрощают работу, так что приведём основные:

BINARY – данные в двоичном виде в диапазоне от 255 до 8000 байт;
RAW – данные фиксированной длинны в двоичном виде в диапазоне до 255 байт;
LONG RAW – данные переменной длины в двоичном виде в диапазоне до 2Гбайт;
VARBINARY – данные переменной длины в двоичном виде в диапазоне до 8000 байт или до 255 байт в зависимости от реализации.

Бинарные типы данных

Хранение типов данных SQL

Расскажем о двух вариантах хранения, которые позволяют хранить объекты LOB, экономя дисковое пространство.

Хранение данных типа FILESTREAM

LOB – большие объекты – хранятся в SQL Server с помощью типа данных MAX или VARBINARY. BLOB — большие двоичные объекты – хранятся в базе данных. Из-за этого могут возникать проблемы с производительностью, когда вы пытаетесь сохранить видео- или аудиофайлы. Во избежание нарушения работы такие данные сохраняют во внешних файлах за пределами базы данных.

Объекты LOB хранятся в файловой системе NTFS. Этот тип хранения позволяет данным, хранящимся вне базы, управляться базой. Основные характеристики:

возможность хранения данных FILESTREAM при помощи инструкций CREATE TABLE, а в процессе работы с этими данными используются инструкции для модификации данных (DELETE, UPDATE, SELECT и INSERT);
обеспечение для данных типа FILESTREAM того же уровня безопасности, что и у данных, которые хранятся внутри базы.

Разреженные столбцы (sparsecolumns)

Этот вариант хранения преследует совершенно иную цель.

Если тип FILESTREAM хранит объекты LOB вне базы данных, то разреженные столбцы минимизируют дисковое пространство, которое занимает база данных.

Это обеспечивает оптимизацию хранения столбцов, у которых большинство значений равняется null. Когда вы используете разреженные столбцы для хранения значений null, вам не требуется дисковое пространство. При этом для хранения значений, которые отличаются от null, потребуется дополнительные байты (от 2 до 4). Поэтому разреженные столбцы рекомендуются к использованию только тогда, когда вы ожидаете сэкономить не менее 20% дискового пространства.

Разреженные столбцы определяют так же, как и другие столбцы таблицы, а значит, обращаются к ним аналогично. При обращении к разреженному столбцу используйте инструкции DELETE, UPDATE , SELECT и INSERT так же, как и при работе с обычными столбцами.

Но всё же есть и отличие: когда вы создаёте разреженные столбцы, применяйте аргумент SPARSE, чтобы определить конкретный столбец разреженным.

Вот пример того, как это сделать:

имя_столбца тип_данных SPARSE

Разреженные столбцы таблицы при необходимости можно группировать в наборы столбцов. Это альтернативный способ хранения значений во всех разреженных столбцах таблицы.

Разреженные столбцы

Значение NULL

«Null» является одним из специальных значений, которые присваивают ячейкам таблиц. Его применяют в тех случаях, когда информация неприменима или совсем неизвестна. Приведём пример, если вы не знаете домашний номер телефона клиента, вы находите столбец home_telephone и присваиваете соответствующей ячейке значение null.

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

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

Бинарные выражения будут действовать так же. Когда A и B равняется null, результат любых операций (умножение, деление, деление по модулю, сложения, вычитания) этих операндов будет тоже обозначен как null.

Когда в выражении содержится операция сравнения, а значение одного или обоих операндов равняется null, результат действия снова будет null.

Обратите внимание, что значение 0, пустой строки и null не должны быть одинаковыми. Значение null всегда отличается от всех остальных значений.

Значение null сохраняется в столбцах таблицы только тогда, когда это явно разрешается определением данного столбца. При этом значения null недоступны для столбца, если в его определении напрямую указано «NOT NULL».

Когда для столбца с каким-либо типом данных не указано напрямую NULL или NOT NULL, мы присваиваем следующие значения:

NULL, когда значение параметров ANSI_NULL_DFLT_ON в инструкции SET равняется on.
NOT NULL, когда значение параметров ANSI_NULL_DFLT_OFF в инструкции SET равняется on.

Если вы не активируете инструкцию set, столбец будет автоматически определяться как NOT NULL. При этом столбцы типа TIMESTAMP не могут иметь значение null ни при каких обстоятельствах.

Преобразование типов данных

Часто возникает необходимость конвертации значений одного типа в значение другого. Как же изменить тип данных в SQL?

Для выполнения конвертирования числа в символьные данные используют специализированную функцию STR. Чтобы выполнить другие преобразования, SQL Server содержит универсальные функции CAST и CONVERT, которые позволяют преобразовывать значения одного типа в значения другого типа. Эти функции взаимозаменяемы. Приведём пример:

Операторы SQL: какие есть и как с ними работать

Ответка

Задайте свой вопрос и получите ответ от профессионального преподавателя. Выберите лучший ответ.

Задать вопрос

Все вопросы

Какой тип данных нужно задать для следующих полей: «Телефон», «Адрес», «Вес»?

Поле «Телефон» будет числового типа, поле «Адрес» — текстовое поле, а поле «Вес» — числовое.
Поле «Телефон» и поле «Адрес» — текстовое поле, а поле «Вес» — числовое.
Поле «Телефон» и поле «Адрес» — числовое поле, а поле «Вес» — текстовое.

Бесплатные вебинары с ответами на все вопросы у нас на канале!

Источник

Если хранить менее 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.

Источник

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

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

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

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

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

1374

15

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. Если бы вы могли управлять вводом, вы могли бы использовать несколько подходов, чтобы сделать данные более полезными, но это не так.

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

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

использовать varchar поле с ограничением по длине.

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

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

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

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

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

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

спасибо.

Источник

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

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

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

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

Обновление: Я не контролирую исходные данные. Просто структура xml файла стандартная. Хотелось бы свести синтаксический анализ xml к минимуму. Как только он будет в базе данных, поиск должен быть быстрым. Есть одно безумное предложение: он должен работать даже с функцией Ajax AutoComplete (чтобы торговые представители могли сразу увидеть подходящие). МОЙ БОГ!!

16 ответы

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

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

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

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

Создан 17 сен.

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

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

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

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

Создан 17 сен.

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

Создан 16 сен.

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

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

Создан 16 сен.

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

Алекс

Создан 16 сен.

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

Создан 16 сен.

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

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

ответ дан 03 мая ’11, 17:05

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

Создан 16 сен.

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

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

Создан 16 сен.

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

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

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

Создан 16 сен.

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

ответ дан 15 авг.

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

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

Создан 22 июля ’13, 10:07

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

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

Спасибо.

ответ дан 12 авг.

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

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

Создан 31 янв.

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

ответ дан 02 апр.

Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками

sql-server
indexing

or задайте свой вопрос.

Источник

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

10 ответов

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

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

Виды типов данных SQL

Строковые типы данных

Числовые типы данных

Типы данных, включающие обозначение даты и времени

Бинарные типы данных

Хранение типов данных SQL

Хранение данных типа FILESTREAM

Разреженные столбцы (sparsecolumns)

Значение NULL

Преобразование типов данных

15 ответов:

16 ответы