Ответ 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/