用于SQL Server中电子邮件地址的NVARCHAR（？）
对于电子邮件地址，我应该给SQL Server中的列多少空间。
我在Wikipedia上找到了这个定义：
http://en.wikipedia.org/wiki/Email_address
电子邮件地址的格式是local-part @ domain，其中本地部分最多可以有64个字符，而域名最多可以有253个字符 - 但正向或反向路径的最大长度为256个字符限制了整个电子邮件地址不得超过254个字符
和这个：
http://askville.amazon.com/maximum-length-allowed-email-address/AnswerViewer.do?requestId=1166932
所以现在，允许电子邮件地址的总字符数是64（本地部分）+1（“@”符号）+ 255（域部分）= 320
将来他们可能会将本地部分限制增加到128个字符。 这将总共384个字符。
有什么想法吗？
我一直使用320根据您的后期计算。 除非有人滥用它和垃圾，否则它不会让你花费更多的钱。 如果他们拥有合法的电子邮件地址长度，现在您必须返回并更新架构，代码和参数等，否则您可能会花费更少的代价，因为您会遇到令人沮丧的用户。在我曾经工作的系统中（一个电子邮件服务提供商），我遇到的最长的电子邮件地址自然是大约120个字符 - 很明显，他们只是为了咧嘴而发一个长的电子邮件地址。
*不完全正确，因为内存许可估计是基于宽度不等的列被半填充的假设，因此存储相同数据的较宽列可能会导致某些查询的性能特性大不相同。
我曾经讨论过NVARCHAR是否是电子邮件地址所必需的。 我还没有遇到过带有Unicode字符的电子邮件地址 - 我知道这个标准支持它们，但是很多现有的系统都不支持它，如果那是你的电子邮件地址，那将是相当令人沮丧的。
虽然NVARCHAR成本是双倍的，但在SQL Server 2008 R2中，您可以从Unicode压缩中受益，Unicode压缩基本上将NVARCHAR列中的所有非Unicode字符视为ASCII，因此您可以将这些额外的字节恢复。 当然，压缩只能在Enterprise +中使用...
减少空间需求的另一种方法是对所有观察到的域名使用中央查找表，并将LocalPart和DomainID与用户一起存储，并且只存储一次唯一的域名。 是的，这使得编程更加繁琐，但是如果您拥有80,000个hotmail.com地址，则成本为80,0000 x 4字节，而不是80,000 x 11个字节（压缩或更少）。 如果存储或I / O是你的瓶颈，而不是CPU，这绝对是一个值得研究的选择。
我在这里写了这个：
http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/
我猜VARCHAR（320）是基于ASCII的域名和电子邮件地址的正常限制。 但是我们不会开始看到unicode域名很快出现吗？
http://en.wikipedia.org/wiki/Internationalized_domain_name
也许NVARCHAR（320）是我们应该开始使用的？
链接地址: http://www.djcxy.com/p/92913.html