В каком типе данных я должен хранить адрес электронной почты в базе данных?

Я понимаю, что 254-символьный адрес электронной почты действителен, но реализации, которые я исследовал, имеют тенденцию использовать varchar (60) для varchar (80) или эквивалент. Например: эта рекомендация SQL Server использует varchar (80) или этот пример Oracle

Есть ли причина не использовать максимум 254 символа? Не содержит ли varchar по определению только столько хранения, сколько необходимо для хранения данных?

Существуют ли существенные последствия /компромиссы в производительности, которые приводят к тому, что многие реализации используют меньше 254 возможных символов?

38 голосов | спросил Thronk 19 MarpmTue, 19 Mar 2013 18:30:10 +04002013-03-19T18:30:10+04:0006 2013, 18:30:10

7 ответов


38

Я всегда использовал VARCHAR(320). Вот почему. Стандарт определяет следующие ограничения:

  • 64 символа для «локальной части» (имя пользователя).
  • 1 символ для символа @.
  • 255 символов для имени домена.

Теперь некоторые люди скажут, что вам нужно больше поддерживать. Некоторые люди также скажут, что вам нужно поддерживать Unicode для доменных имен (это означает, что вам нужно переключиться на NVARCHAR). Хотя стандарт может меняться в то же время (прошло некоторое время с тех пор, как у меня была кожа в игре), я вполне уверен, что в это время большинство серверов в мире не будут принимать адреса электронной почты Unicode, и я уверен многие серверы будут создавать проблемы и /или принимать адреса с помощью> 320 символов.

Тем не менее, вы можете подготовиться к худшему сейчас, если хотите (и если вы используете сжатие данных в SQL Server 2008 R2 или выше, вы выиграете от сжатия Unicode, то есть вы платите только 2 байта за персонажей это действительно нужно). Таким образом, вы можете сделать свою колонку столь же широкой, как вы хотите, и вы можете позволить людям набить слишком длинный мусор, который они хотят - они не получат сообщение по электронной почте, если они дадут вам мусор, как будто они не будут получите электронное письмо, если сбой вставки. Проблема в том, что если вы допустили недопустимый мусор, вы должны иметь дело с ним. И независимо от того, какой размер вы это сделаете, - если кто-то попытается набрать 400 символов в столбе из 320 символов, кто-то попытается заполнить 1025 символов в столбце с 1024 символами. Нет причин, по которым разумный человек должен иметь адрес электронной почты> 320 символов, если они не используют его для явного тестирования границ системы.

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


EDIT благодаря @ypercube для ping в чате.

В стороне, возможно, вы не хотите, чтобы выгрузить весь адрес в один столбец в первую очередь. Нормализация может предполагать, что вы не хотите хранить @hotmail.com 15 миллионов раз, когда многослойный FK int будет работать нормально и не будет иметь дополнительных накладных расходов столбцов переменной длины. Вы также можете нормализовать имя пользователя, так как [email protected] и [email protected] поделиться общим именем пользователя - они не знают друг друга, но ваша база данных не заботится об этом.

Я говорил об этом здесь:

http://www.mssqltips.com/sqlservertip /2657 /хранения, почтовые адреса-более-эффективно-в-SQL-сервер /

http: //www .mssqltips.com /sqlservertip /2671 /хранящая-почтовый-адрес-более эффективно-в-SQL-сервер - часть-2 /

Это вводит проблемы, однако, в 254-символьный предел выше, поскольку, похоже, не существует консенсуса относительно того, что происходит, когда действительный 255-символьный домен объединяется с действительной 1-символьной локальной частью. Это должно быть принято большинством серверов по всему миру, но, похоже, нарушает этот предел в 254 символа. Итак, вы создаете таблицу Domains, которая имеет искусственно меньшее ограничение длины для адресов электронной почты, когда домен может быть повторно использован как допустимый URL-адрес из 255 символов

ответил Aaron Bertrand 19 MarpmTue, 19 Mar 2013 18:59:27 +04002013-03-19T18:59:27+04:0006 2013, 18:59:27
5

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

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

Это приводит меня к следующему пункту. База данных, скорее всего, является только уровнем данных. Что использует уровень приложения? Например, если у вас есть приложение, в котором вы можете ввести только 80 символов для адреса электронной почты, почему вы хотите, чтобы тип данных был больше? Бизнес должен ответить на два вопроса:

  1. Что может быть может ?
  2. Что должно быть?

Только тогда вы получите ответ.

  

Не содержит ли varchar по определению только столько хранения, сколько необходимо для хранения данных?

Да и нет. Для записи данных переменной длины будет какое-то смещение для записи длины.

ответил Thomas Stringer 19 MarpmTue, 19 Mar 2013 18:45:45 +04002013-03-19T18:45:45+04:0006 2013, 18:45:45
3

RFC 5321 (текущая спецификация SMTP, устаревшая RFC2821):

  

Максимальная общая длина имени пользователя или другой локальной части - 64   октет.   Максимальная общая длина имени или номера домена составляет 255 октетов

Знак 64 + 255 + @ означает VARCHAR (320). Вероятно, вам это никогда не понадобится, но на всякий случай это безопасно.

ответил avakharia 19 MarpmTue, 19 Mar 2013 18:58:57 +04002013-03-19T18:58:57+04:0006 2013, 18:58:57
1

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

Так как длина столбца VARCHAR действительно является «максимальной длиной», она должна быть установлена ​​больше максимальной длины, возможной при любых обстоятельствах. Будет использоваться только столько места, сколько потребуется каждой строке. Затем прикладные программы должны быть спроектированы с прокручиваемыми полями или тем, что имеет смысл на основе типичных значений.

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

Хотя команда увеличения размера VARCHAR может выглядеть просто и запускаться мгновенно на маленькой таблице, для этого в таблице с тысячами строк или более, вероятно, потребуется некоторое количество запросов к базе данных при регенерации всех данных и индекса блоки. Один из способов - скопировать все в новую таблицу с большими столбцами. Какая бы техническая техника не использовалась, это крупно-волосатая сделка. Таким образом, вы должны учитывать размер столбца VARCHAR, который в значительной степени неизменен после загрузки рабочей таблицы.

ответил DocSalvager 27 MarpmWed, 27 Mar 2013 12:59:05 +04002013-03-27T12:59:05+04:0012 2013, 12:59:05
1

Как комментарий к отличным ответам уже здесь:

Во-первых, если вы создали поле как varchar(240), и вы хотите позже изменить его на более длинное поле, скажем varchar(320), это изменение должна быть тривиальной операцией на сервере базы данных - в зависимости, конечно, от вашего продукта базы данных.

alter table Schema.Object alter column EmailAddress varchar(320) ;

Во-вторых, в зависимости от среднего размера строки и размера страницы использование varchar(320) вместо varchar(240) может не изменить количество выделенных страниц ( дисковое пространство, фактически занятое таблицей).

В-третьих, кто-то выше говорил об утверждении адреса электронной почты. Я утверждаю, что есть только один верный способ проверить адрес электронной почты и отправить ему электронное письмо. : -)

ответил Greenstone Walker 20 MaramWed, 20 Mar 2013 10:46:31 +04002013-03-20T10:46:31+04:0010 2013, 10:46:31
1

Использование SQL DOMAIN

Если вы используете сервер Enterprise Database, должно быть каким-то образом сохранить адрес электронной почты как DOMAIN с некоторым уровнем достоверности. Домены указаны в спецификации SQL

  

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

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

  • Создайте собственный DOMAIN по спецификации HTML5 электронной почты.
  • Или, по спецификации RFC822, RFC2822, RFC5322 электронной почты.
  • Создайте собственный DOMAIN, который проверяет сервер на MX-запись во время проверки.

Я оцениваю эти параметры в этом ответе, который специфичен для PostgreSQL

ответил Evan Carroll 2 MarpmThu, 02 Mar 2017 19:21:41 +03002017-03-02T19:21:41+03:0007 2017, 19:21:41
0

VARCHAR - лучший тип данных, который будет использоваться для адресов электронной почты, поскольку электронные письма сильно различаются по длине. NVARCHAR также является альтернативой, но я бы рекомендовал использовать его только в том случае, если адрес электронной почты содержит расширенные символы и имейте в виду, что для него требуется двойной объем пространства по сравнению с VARCHAR.

В моей среде мы используем varchar (70), поскольку самые длинные из них, с которыми я столкнулся, тесно связаны на 60-70 символов, но это зависит и от клиентской базы вашей компании. Кроме того, в качестве примечания, убедитесь, что у вас есть проверка подлинности электронной почты на месте для достоверности адресов электронной почты .. например, с использованием проверочных ограничений или CHARINDEX

ответил Kin 19 MarpmTue, 19 Mar 2013 18:47:17 +04002013-03-19T18:47:17+04:0006 2013, 18:47:17

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

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

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