NVARCHAR(?) Для адресов электронной почты в SQL Server

Question

Для адресов электронной почты, сколько места я должен дать столбцы в SQL Server.

Я нашел это определение в Википедии:

http://en.wikipedia.org/wiki/Email_address

Формат адресов электронной почты - local-part@domain, где local-part может иметь длину до 64 символов, а имя домена может содержать не более 253 символов, но максимальная длина 256 символов прямого или обратного пути ограничивает весь путь. адрес электронной почты должен быть не более 254 символов

И этот:

http://askville.amazon.com/maximum-length-allowed-email-address/AnswerViewer.do?requestId=1166932

Таким образом, на данный момент общее количество символов, разрешенных для адреса электронной почты, составляет 64 (локальная часть) + 1(знак "@") + 255 (часть домена) = 320

Возможно, что в будущем они увеличат лимит локальной части до 128 символов. что составит в общей сложности 384 символов.

Какие-нибудь мысли?

Answer 1

Я всегда использовал 320 на основе вашего последнего расчета. Вам не нужно ничего доплачивать *, если только люди не злоупотребляют этим и не загружают туда мусор. Это может стоить вам позволить меньше, так как у вас будут разочаровывающие пользователи, если у них законно более длинные адреса электронной почты, и теперь вам придется возвращаться и обновлять схему, код, параметры и т. Д. В системе, которую я использовал для работы с (поставщиком услуг электронной почты) самый длинный адрес электронной почты, с которым я столкнулся, составлял приблизительно 120 символов - и было ясно, что они просто делали длинный адрес электронной почты для усмешек.

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

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

И хотя это правда, что NVARCHAR стоит вдвое больше места, с SQL Server 2008 R2 вы можете извлечь выгоду из сжатия Unicode, которое в основном обрабатывает все не-Unicode символы в NVARCHAR столбец как ASCII, так что вы получите эти дополнительные байты обратно. Конечно, сжатие доступно только в Enterprise+...

Другой способ уменьшить требования к пространству - использовать центральную справочную таблицу для всех наблюдаемых доменных имен и хранить LocalPart а также DomainID с пользователем, и сохраняйте каждое уникальное доменное имя только один раз. Да, это делает более громоздким программирование, но если у вас есть 80000 адресов hotmail.com, стоимость составляет 80000 x 4 байта вместо 80000 x 11 байтов (или меньше при сжатии). Если узким местом является хранилище или ввод-вывод, а не процессор, то этот вариант определенно стоит изучить.

Я написал об этом здесь:

http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/

Answer 2

Я думаю, VARCHAR(320) будет нормальным пределом для доменного имени и адреса электронной почты на основе ASCII. Но разве мы не начнем видеть доменные имена Unicode, появляющиеся в ближайшее время?

http://en.wikipedia.org/wiki/Internationalized_domain_name

Может быть, NVARCHAR(320) - это то, что мы должны начать использовать?