Безопасный SQL
  1. Безопасный SQL
  3. Как долго должны быть поля электронной почты SQL?
Intereting Posts
SUM () на основе другого условия для SELECT Преобразование строки в столбцы SQL Server 2008, сколько места занимает это занятие? Условный INSERT с SQL? Обновление нескольких столбцов для нескольких строк в одном запросе SQL Как использовать переменные скрипта в PostgreSQL? SQL-отчет: нулевой параметр xp_cmdshell Длина запроса слишком большая MySQL – соединение между таблицами в двух разных базах данных? Обновление с функцией, вызываемой один раз для каждой строки в Postgres 8.4 взяться за первое исполнение в Ruby on Rails Когда или почему вы используете правое внешнее соединение вместо левого? запрос игнорировать дубликаты / нулевые записи SQL: «Обратный» транспонировать таблицу Как эффективно создавать базу данных MySQL для моего конкретного случая

Как долго должны быть поля электронной почты SQL?

Я признаю, что адрес электронной почты в принципе может быть бесконечно длинным, поэтому любой размер, который я налагаю на свое поле адреса электронной почты varchar, будет произвольным. Однако мне было интересно, что такое «стандарт»? Как долго вы это делаете? (тот же вопрос для поля Name …)

update: По-видимому, максимальная длина для адреса электронной почты составляет 320 (<= 64 именная часть, <= 255 домен). Вы используете это?

Теоретический предел действительно длинный, но вам действительно нужно беспокоиться об этих длинных адресах электронной почты? Если кто-то не может войти в систему с электронной почтой 100-char, вам все равно? Мы на самом деле предпочитаем, чтобы они не могли.

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

  1. Самый длинный действительный – 89.
  2. Есть сотни более длинных до предела нашей колонки (255), но они, по-видимому, поддельны визуальным контролем.
  3. Пик распределения длины равен 19.
  4. Нет длинного хвоста. После 38 лет все резко падает.

Мы очистили БД, выбросив все дольше, чем 40. Хорошей новостью является то, что никто не жаловался, но плохие новости – это не так много записей, которые были очищены.

В прошлом я только что сделал 255, потому что это так укоренившийся стандарт короткого, но не слишком короткого ввода. Это, и я – привычка.

Однако, поскольку max 319, я бы сделал nvarchar(320) в столбце. Должен помнить @ !

nvarchar не будет использовать пространство, которое вам не нужно, поэтому, если у вас есть только 20-символьный адрес электронной почты, он будет занимать до 20 байт. Это контрастирует с nchar который всегда будет поднимать свой максимум (он правильно nchar значение на пробелы).

Я также использовал nvarchar вместо varchar так как это Unicode. Учитывая волатильность адресов электронной почты, это определенно путь.

Следующий адрес электронной почты составляет всего 94 символа:

i.have.a.really.long.name.like.seetharam.krishnapillai@AReallyLongCompanyNameOfSomeKind.com.au

вы бы действительно использовали такой адрес электронной почты? Кто-нибудь? Конечно нет. Слишком долго печататься и слишком сложно запомнить.

Если дисковое пространство в вашей БД является проблемой, и вы не возражаете, если один пользователь из миллиона должен использовать дополнительный адрес электронной почты для использования вашего сайта, перейдите на 50 символов: 123456789.123456789.123456789@1234567890123456.com

(Опять же, большая часть времени, дисковое пространство больше не проблема, не так ли?)

Если вы действительно в курсе, сделайте имя пользователя varchar (60), домен varchar (255). Затем вы можете делать смешные статистические данные об использовании домена, которые немного быстрее, чем делать это как одно поле. Если вы настроитесь на оптимизацию, это также сделает ваш SMTP-сервер способным отправлять электронные письма с меньшим количеством соединений / более эффективной дозировкой.

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

4.5.3.1.1. Локальная часть

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

4.5.3.1.2. Домен

Максимальная общая длина имени или номера домена составляет 255 октетов.

Это относится только к локальному домену @ domain, в общей сложности 320 символов ASCII (7 бит).

Если вы планируете нормализовать свои данные, возможно, разделив локальную часть и домен на отдельные поля, добавьте дополнительные вещи, чтобы иметь в виду:

  • Метод, известный как VERP, может привести к созданию полноразмерных локальных частей для автоматически генерируемой почты (может не иметь отношения к вашему прецеденту)
  • домены нечувствительны к регистру; рекомендовать понижать область домена
  • localparts чувствительны к регистру; user@domain.com и USER@domain.com являются технически разными адресами в спецификациях, хотя политика на domain.com может заключаться в том, чтобы рассматривать два адреса как эквивалентные. Лучше всего ограничивать локальную разбивку дел в доменах, которые, как известно, делают это.

Согласно этому тексту, на основе соответствующих документов RFC, это не 320, а 254: http://www.eph.co.uk/resources/email-address-length-faq/

Я использую varchar (64), я не думаю, что у кого-то может быть больше электронной почты

Для электронной почты, независимо от спецификации, я практически всегда иду с 512 (nvarchar). Имена и фамилии похожи.

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

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