Я всегда использовал 320 на основе вашего последнего расчета. Вам ничего не стоит позволить больше *, если только люди не злоупотребляют этим и не набивают ерунду. может стоить , чтобы позволить вам меньше, так как у вас будут разочаровывающие пользователи, если у них законно более длинные адреса электронной почты, и теперь вам придется возвращаться и обновлять схему, код, параметры и т. Д. В система, с которой я работал (поставщик услуг электронной почты), самый длинный адрес электронной почты, с которым я столкнулся, составлял приблизительно 120 символов - и было ясно, что они просто делают длинный адрес электронной почты для ухмылок.
* Не совсем верно, поскольку оценки предоставления памяти основаны на предположении, что столбцы переменной ширины заполнены наполовину, поэтому более широкий столбец, в котором хранятся одни и те же данные, может привести к очень разным характеристикам производительности некоторых запросов.
И я спорил, нужен ли NVARCHAR для адреса электронной почты. Я еще не сталкивался с адресом электронной почты с символами Unicode - я знаю, что стандарт поддерживает их, но многие существующие системы этого не делают, было бы довольно неприятно, если бы это был ваш адрес электронной почты.
И хотя действительно, что NVARCHAR стоит вдвое больше места, с SQL Server 2008 R2 вы можете извлечь выгоду из сжатия Unicode, которое в основном обрабатывает все не-Unicode символы в столбце NVARCHAR как ASCII, так что вы получаете эти дополнительные байты назад. Конечно, сжатие доступно только в Enterprise + ...
Другой способ уменьшить требования к пространству - это использовать центральную таблицу поиска для всех наблюдаемых доменных имен, хранить LocalPart и DomainID с пользователем и сохранять каждое уникальное доменное имя только один раз. Да, это делает более громоздким программирование, но если у вас есть 80 000 адресов hotmail.com, стоимость составляет 80 000 x 4 байта вместо 80 000 x 11 байтов (или меньше при сжатии). Если узким местом является хранилище или ввод-вывод, а не процессор, это определенно стоит изучить.
Я писал об этом здесь:
http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/