Какова оптимальная длина адреса электронной почты в базе данных?
вот извлеченная часть моего запроса, отражающая EMAIL_ADDRESS
тип и свойство данных столбца:
EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL,
однако Джон Сондерс использует VARYING(256)
.
Это говорит о том, что я не обязательно правильно понял варьирование.
Я понимаю это так, что длина адреса электронной почты составляет 20 символов в моем случае, в то время как 256 для Jodn.
контекст в коде
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 символов, используемых обычными людьми.
какова оптимальная длина адреса электронной почты в базе данных?
8 ответов:
максимальная длина адреса электронной почты составляет 254 символа.
каждый адрес электронной почты состоит из двух частей. Локальная часть, которая находится перед знаком'@', и доменная часть, которая следует за ним. В "user@example.com", локальная часть-это "пользователь", а доменная часть - "example.com".
локальная часть не должна превышать 64 символов, а доменная часть не может быть длиннее 255 символов.
объединенная длина локальных + @ + доменных частей адрес электронной почты не должен превышать 254 символов. Как описано в RFC3696 Errata ID 1690.
мои данные поступают из базы данных 323 адреса. Распределение имеет некоторые верхние конечные выбросы (положительно-перекошено). Это нормально распространяется без исключения (я проверить его.)
мин: 12 1-й квартиль: 19 среднее (Вт/ выбросы): 23.04 означает без выбросов): 22.79 3-й квартиль: 26 Макс (без выбросов): 47 Макс (без выбросов): 35
Медиана: 23 Режим: 24 Std. Дев (Вт/ останцы): 5.20 Станд. Dev (w / o останцы): 4.70
диапазоны на основе данных, включая выбросы 68.2% данных 17.8 - 28.2 - 33.4 95,4% от данных 12.6 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):
мой рабочий адрес электронной почты более 20 символов!
читать соответствующую спецификация RFC:
"локальная часть адреса электронной почты может быть до 64 символов длиной и доменное имя может иметь максимум 255 символов"
просто использовать
varchar(50)
. Более длинные письма-это дерьмо, каждый раз.просто посмотрите, как долго 50 символов:
peoplewithanemail@ddressthislongjustuseashorterone
Если вы разрешаете 255 символов электронной почты:
- отображение их может испортить ваш пользовательский интерфейс (в лучшем случае они будут отрезаны, в худшем они толкают ваши контейнеры и поля вокруг) и
- вредоносные пользователи могут делать с ними то, что вы не можете предвидеть (например, те случаи, когда хакеры использовали бесплатный онлайн API для хранения кучи данных)
(статистика показывает, что никто на самом деле не вводит более 50 символов для законного адреса электронной почты, см., например: ответ пейджмена https://stackoverflow.com/a/1199245/87861)
как говорили другие, намного больше, чем 20. 256 + 64 звучит хорошо для меня и соответствует RFC.
единственная причина не иметь такое большое значение для вашей базы данных, если вы беспокоитесь о производительности или пространстве, и если вы делаете это, то я 99.99999999999999% уверен, что это преждевременная оптимизация.
смотреть на большом экране.
переменные символьные типы в базах данных не занимают ненужного места. Таким образом, нет причин максимально ограничивать такие поля. В зависимости от имени человека, схемы именования, используемой их организацией и их доменным именем, адрес может легко превышать 20 символов.
нет ограничений по длине локальной части и доменного имени в RFC-2822. RFC-2181 ограничивает доменное имя до 255 октетов / символов хотя.
опять же, так как тип varchar использует только пространство, фактически используемое строкой, которую вы храните, нет причин иметь небольшой предел для длины адреса электронной почты. Просто иди с 512 и перестань волноваться. Все остальное преждевременная оптимизация
первоначально максимум 320 символов (64+1+255, как показывают в других ответах) но как RFC 3696 Errata 1003 сказал:
однако в RFC 2821 существует ограничение на длину адрес в почте и команды RCPT 256 символов. Так как адреса которые не вписываются в эти поля обычно не полезны, верхний ограничение на длину адреса обычно должно рассматриваться как 256.
4.5.3.1.3. Путь
максимальная общая длина обратного или прямого пути составляет 256 октеты (включая знаки препинания и разделители элементов)
это в том числе открытие и закрытие скобок, так что давайте только 254 октетов адреса электронной почты.
но имейте в виду, что количество октетов не может быть равно количеству символов (a char может иметь 2 или более октетов). Кроме того,RFC раздел 4.5.3.1 скажите, что могут быть поля больше, чем максимум и это возможно, но не гарантировано серверам, чтобы поймать их правильно.
и тогда вы можете/должны использовать
VARCHAR(254)
для сохранения адреса электронной почты.Примечание: в MySQL, по крайней мере, столбец объявлен как
VARCHAR
ничуть меньше или равно 255 октетов будут сохранены как1 byte + length
(1 для хранения длины) так что пространство не получается, если используется ниже предел.
поле CHAR(20) всегда будет занимать 20 символов, независимо от того, используете ли вы его все или нет. (Часто дополняется пробелами в конце.) Поле VARCHAR (20) займет до 20 символов, но может занять меньше. Одним из преимуществ постоянной ширины CHAR()является быстрый переход к строке в таблице, потому что вы можете просто вычислить индекс, на котором он должен быть. Недостатком является потеря пространства.
преимущество char(x) постоянного размера теряется, если у вас есть какие-либо столбцы VARCHAR(x) в вашем стол. Я, кажется, помню, что MySQL молча преобразовал любые поля CHAR () в VARCHAR () за кулисами, если некоторые столбцы были VARCHAR () s.