有没有理由不使用最多254个字符？根据定义,varchar不能仅使用保存数据所需的存储空间吗？
是否有重要的性能影响/折衷导致如此多的实现使用少于完整的254个可能的字符？
解决方法
>“本地部分”(用户名)> 64个字符.
@符号> 1个字符.
>域名的255个字符.
现在,有些人会说你需要支持更多.有些人还会说你需要支持域名的Unicode(这意味着你必须切换到NVARCHAR).虽然标准可能会在此期间发生变化(自从我在游戏中拥有皮肤以来已经有一段时间了),我非常有信心,此时世界上大多数服务器都不会接受Unicode电子邮件地址,我相信许多服务器在使用>创建和/或接受地址时会遇到问题320个字符.
也就是说,如果您愿意,可以为最坏的情况做好准备(如果您在sql Server 2008 R2或更高版本中使用数据压缩,您将受益于Unicode压缩,这意味着您只需为实际需要的字符支付2字节的罚款它).通过这种方式,你可以让你的专栏尽可能宽,你可以让人们把他们想要的任何太长的垃圾塞进Go – 他们不会收到电子邮件,如果他们给你垃圾就像他们不会如果插入失败,则会收到一封电子邮件.问题是如果你让无效的垃圾进入,你必须处理它.无论你做出多大的规模 – 如果有人试图将400个字符填充到320个字符的列中,有人会尝试将1025个字符填充到1024个字符的列中.没有理由任何明智的人应该有一个电子邮件地址> 320个字符,除非他们使用它来明确测试系统边界.
但是不要再就这个问题征求意见了 – 并且停止查看其他实现以获得指导(在这种情况下恰好发生了这样的情况,即您引用的那些并没有费心去做他们自己的功课,只是选择了他们的数字,嗯,你知道) . You have direct access to the standard – 确保您查阅最新版本,至少支持该版本,并始终遵守标准,以便您可以适应规格的变化.
编辑感谢@ypercube在聊天中ping.
顺便说一句,也许您不希望首先将整个地址转储到单个列中.规范化可能表明,当一个更瘦的FK int工作得很好并且没有可变长度列的额外开销时,你不想存储@ hotmail.com 1500万次.您也可以规范化用户名,因为john.smith@hotmail.com和john.smith@gmail.com共享一个共同的用户名 – 他们彼此不认识,但您的数据库并不关心.
我在这里谈到了一些：
http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/
然而,这引入了对上述254个字符限制的挑战,因为当有效的255个字符的域与有效的1个字符的localpart结合时,似乎没有达成共识.这应该被世界上大多数服务器接受,但似乎违反了这个254个字符的限制.那么,当域可以重新用作有效的255个字符的URL时,您是否创建了一个对电子邮件地址的长度限制有人为限制的域表？
