Какова оптимальная длина электронного адреса в базе данных?

Вот извлеченная часть моего запроса, отражающая EMAIL_ADDRESSтип данных и свойство столбца:

EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL, 

Однако Джон Сондерс использует VARYING(256).

Это наводит на мысль, что я не обязательно правильно понял РАЗЛИЧНЫЕ.

Я так понимаю, что длина адреса электронной почты в моем случае составляет 20 символов, а для Jodn - 256.

Контекст в коде Джона

CREATE TABLE so."User"
  (
    USER_ID SERIAL NOT NULL,
    USER_NAME CHARACTER VARYING(50) NOT NULL,
    EMAIL_ADDRESS CHARACTER VARYING(256) NOT NULL, // Here
    HASHED_PASSWORD so.HashedPassword NOT NULL,
    OPEN_ID CHARACTER VARYING(512),                                                         
    A_MODERATOR BOOLEAN,
    LOGGED_IN BOOLEAN,
    HAS_BEEN_SENT_A_MODERATOR_MESSAGE BOOLEAN,
    CONSTRAINT User_PK PRIMARY KEY(USER_ID)
  );

Я никогда не видел, чтобы адреса электронной почты длиннее 20 символов использовались обычными людьми.

Какова оптимальная длина электронного адреса в базе данных?

Максимальная длина адреса электронной почты - 254 символа.

Каждый адрес электронной почты состоит из двух частей. Локальная часть, которая стоит перед знаком «@», и доменная часть, которая следует за ним. В «user@example.com» локальная часть - «user», а часть домена - «example.com».

Локальная часть не должна превышать 64 символа, а часть домена не может быть длиннее 255 символов.

Общая длина локальных + @ + доменных частей адреса электронной почты не должна превышать 254 символа. Как описано в RFC3696 Errata ID 1690 .

Я получил исходную часть этой информации отсюда

из Ask Metafilter :

Мои данные взяты из базы данных из 323 адресов. Распределение имеет некоторые выбросы в верхней части (с положительным перекосом). Обычно он распространяется без выбросов (я его тестировал).

Мин .: 12 1-й квартиль: 19 Среднее (без выбросов): 23,04 Среднее без выбросов): 22,79 3-й квартиль: 26 Макс. (Без выбросов): 47 Макс. (Без выбросов): 35

Медиана: 23 Режим: 24 Станд. Разработка (без выбросов): 5.20 Станд. Разработка (без выбросов): 4.70

Диапазоны на основе данных, включая выбросы 68,2% данных 17,8 - 28,2 95,4% данных 12,6 - 33,4 99,7% данных 7,4 - 38,6

Диапазоны, основанные на выбросах данных, исключены 68,2% данных 18,1 - 27,5 95,4% данных 13,4 - 32,2 99,7% данных 8,7 - 36,9

Если вы зарегистрируетесь на http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/, то ваш адрес электронной почты наверняка будет исключением :)

Вот какова максимальная безопасная длина адреса электронной почты, разрешенная в форме веб-сайта? на Raycon с немного другим средним значением (N = 50 496, среднее = 23):

Просто используйте varchar(50). Каждый раз длинные электронные письма - это дерьмо.

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

peoplewithanemail @ ddressthislongjustuseashorterone

Если вы разрешаете 255-символьные электронные письма:

• Их отображение может испортить ваш пользовательский интерфейс (в лучшем случае они будут отключены, в худшем - они вытеснят ваши контейнеры и поля) и
• Злоумышленники могут делать с ними то, чего нельзя ожидать (например, те случаи, когда хакеры использовали бесплатный онлайн-API для хранения большого количества данных)

(Статистика показывает, что на самом деле никто не вводит более 50 символов для законного адреса электронной почты, см., Например, ответ пейджмена https://stackoverflow.com/a/1199245/87861 )

Мой рабочий адрес электронной почты превышает 20 символов!

Прочтите соответствующую спецификацию RFC :

«Локальная часть адреса электронной почты может иметь длину до 64 символов, а имя домена - до 255 символов»

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

В RFC-2822 нет ограничений на длину локальной части и имени домена . RFC-2181 ограничивает доменное имя 255 октетами / символами.

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

Первоначально максимум составляет 320 символов (64 + 1 + 255, как показано в других ответах), но, как сказано в RFC 3696 Errata 1003 :

Однако в RFC 2821 есть ограничение на длину адреса в командах MAIL и RCPT в 256 символов. Поскольку адреса, которые не помещаются в эти поля, обычно бесполезны, верхний предел длины адреса обычно считается равным 256.

И из раздела 4.5.3.1.3 RFC 5321 :

4.5.3.1.3. Путь

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

Это включает открывающие и закрывающие скобки, поэтому мы можем использовать только 254 октета адреса электронной почты.

Но имейте в виду, что количество октетов может не совпадать с количеством символов (у char может быть 2 или более октета). Также в разделе 4.5.3.1 RFC говорится, что могут быть поля, превышающие максимум, и это возможно, но не гарантируется, чтобы серверы правильно их поймали.

И тогда вы можете / должны использовать a VARCHAR(254)для хранения адреса электронной почты.

Примечание. По крайней мере, в MySQL столбец, объявленный как значение, VARCHARменьшее или равное 255 октетам, будет сохранен как 1 byte + length(1 - для хранения длины), поэтому при использовании нижнего предела места не будет.

Как говорили другие, намного больше 20. 256 + 64 звучит хорошо для меня и соответствует RFC.

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

Стань большим.

Поле CHAR (20) всегда будет занимать 20 символов, независимо от того, используете вы его все или нет. (Часто дополняются пробелами в конце.) А VARCHAR (20) поля будет занимать до 20 символов, но может занять меньше. Одним из преимуществ постоянной ширины CHAR () является быстрый переход к строке в таблице, потому что вы можете просто вычислить индекс, в котором она должна находиться. Недостаток - бесполезная трата места.

Преимущество CHAR (x) постоянного размера теряется, если в вашей таблице есть столбцы VARCHAR (x). Кажется, я припоминаю, что MySQL незаметно преобразовал любые поля CHAR () в VARCHAR () за кулисами, если некоторые столбцы были VARCHAR () s.