对于电子邮件地址，我应该在 SQL Server 中为各列提供多少空间。
我在维基百科上找到了这个定义:
http://en.wikipedia.org/wiki/Email_address
The format of email addresses is local-part@domain where the local-part may be up to 64 characters long and the domain name may have a maximum of 253 characters - but the maximum 256 characters length of a forward or reverse path restricts the entire email address to be no more than 254 characters
还有这个:
http://askville.amazon.com/maximum-length-allowed-email-address/AnswerViewer.do?requestId=1166932
So for now, total characters allowed for e-mail address is 64 (local part) + 1("@" sign) + 255 (domain part) = 320
It's possible that in the future they'll increase the local-part limit to 128 characters. which would make total of 384 characters.
有什么想法吗？
最佳答案
根据你后面的计算，我一直使用 320。允许更多*不需要花费任何费用，除非人们滥用它并在其中塞入垃圾。允许更少的可能会让您付出代价，因为如果用户拥有合法的更长的电子邮件地址，您将会感到沮丧，而现在您必须返回并更新架构、代码、参数等。在我曾经使用的系统(电子邮件服务提供商)中，我自然遇到的最长电子邮件地址大约有 120 个字符 - 很明显，他们只是为了微笑而制作一个很长的电子邮件地址。
* Not strictly true, since memory grant estimates are based on the assumption that varying-width columns are half-populated, so a wider column storing the same data can have lead to vastly different performance characteristics of certain queries.
我也曾争论过 NVARCHAR 对于电子邮件地址是否是必要的。我还没有遇到过带有 Unicode 字符的电子邮件地址 - 我知道标准支持它们，但许多现有系统不支持，如果那是您的电子邮件地址，那将非常令人沮丧。
虽然 NVARCHAR 确实会花费双倍的空间，但使用 SQL Server 2008 R2，您可以从 Unicode 压缩中受益，它基本上会处理 NVARCHAR 中的所有非 Unicode 字符> 列为 ASCII，这样您就可以取回那些额外的字节。当然压缩仅在 Enterprise+ 中可用...
减少空间需求的另一种方法是对所有观察到的域名使用中央查找表，并与用户一起存储 LocalPart 和 DomainID，并存储每个唯一的域只命名一次。是的，这会使编程变得更加麻烦，但如果您有 80,000 个 hotmail.com 地址，则成本为 80,0000 x 4 字节，而不是 80,000 x 11 字节(或压缩后更少)。如果存储或 I/O 是您的瓶颈，而不是 CPU，那么这绝对是一个值得研究的选项。
我在这里写过这个:
关于sql - NVARCHAR(?) 用于 SQL Server 中的电子邮件地址，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9295513/