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

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

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

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

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

И этот:

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

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

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

Любые мысли?

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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