用于SQL Server中电子邮件地址的NVARCHAR（？）

对于电子邮件地址，我应该为SQL Server中的列提供多少空间。用于SQL Server中电子邮件地址的NVARCHAR（？）

我发现维基百科这样的定义：

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个字符。

有什么想法？

来源

2012-02-15 tugberk

我一直使用320基于你的后期计算。除非有人滥用它和垃圾，否则它不会让你花费更多的钱。它可能花费你允许更少，因为如果他们有合法的更长的电子邮件地址，你将有一个令人沮丧的用户，现在你将不得不返回并更新架构，代码，参数等。在我使用的系统（电子邮件服务提供商）合作时，我遇到的最长的电子邮件地址自然是大约120个字符 - 很明显，他们只是为了一个很长的电子邮件地址。

* 不是严格正确的，因为内存授予估计是基于这样的假设不同宽度的列的一半填充，因此更宽的列存储相同数据可具有导致某些查询的完全不同的性能特性。

而且我辩论NVARCHAR是否是必要的E-mail地址。我还没有遇到过带有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/

来源

2012-02-15 14:53:19

@tugberk对不起，在通知延迟，但我写了关于这里：http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/ – 2013-02-28 16:52:15

只为info：ASP.NET成员资格提供程序为Email字段使用“nvarchar（256）”创建数据库“AspNetUsers”。 – Yanga 2017-09-30 05:01:57

@Yanga呃，谢谢你。 – 2017-09-30 09:34:59

我猜VARCHAR（320）将是基于ASCII的域名和电子邮件地址的正常范围。但是我们不会开始看到unicode域名很快出现吗？

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

也许NVARCHAR（320）是我们应该开始使用？

来源

2012-02-15 14:58:17

我真的相信，在我们开始在域名和电子邮件地址中广泛采用Unicode字符之前，这将是一段很长的时间。只有电子邮件服务器的数量才会对它们造成巨大的冲击...... – 2012-02-15 15:00:48

你说得对。如果我们关心这个长度，我们应该为unicode做同样的事情。 – tugberk 2012-02-15 15:01:56

用于SQL Server中电子邮件地址的NVARCHAR（？）

回答

相关问题