Thr*_*onk 51 database-design datatypes
我知道 254 个字符的电子邮件地址是有效的，但我研究过的实现倾向于使用 varchar(60) 到 varchar(80) 或等效的。例如：此 SQL Server 推荐使用 varchar(80) 或此 Oracle 示例
是否有理由不使用最多 254 个字符？根据定义，varchar 不是只使用保存数据所需的存储空间吗？
是否存在显着的性能影响/权衡导致如此多的实现使用少于完整的 254 个可能字符？
Aar*_*and 52
我一直都在用VARCHAR(320)。这是为什么。该标准规定了以下限制：
@符号1 个字符。现在，有些人会说你需要的支持不止于此。有些人还会说您需要支持 Unicode 域名（意味着您必须切换到NVARCHAR）。虽然标准在此期间可能会发生变化（我已经有一段时间没有在游戏中使用皮肤了），但我非常有信心此时世界上大多数服务器都不会接受 Unicode 电子邮件地址，我敢肯定许多服务器在创建和/或接受大于 320 个字符的地址时会遇到问题。
也就是说，如果您愿意，您现在可以为最坏的情况做好准备（如果您在 SQL Server 2008 R2 或更高版本中使用数据压缩，您将受益于 Unicode 压缩，这意味着您只需为实际需要的字符支付 2 字节的损失它）。通过这种方式，您可以根据需要使您的专栏尽可能宽，并且您可以让人们在那里塞入他们想要的任何太长的垃圾 - 如果他们给您垃圾，他们将不会收到电子邮件，就像他们不会一样如果插入失败，将收到一封电子邮件。问题是如果你让无效的垃圾进来，你必须处理它。而且无论您制作什么尺寸 - 如果有人尝试将 400 个字符填充到 320 个字符的列中，那么有人会尝试将 1025 个字符填充到 1024 个字符的列中。任何明智的人都没有理由拥有超过 320 个字符的电子邮件地址，除非他们使用它来明确测试系统边界。
但是不要就此征求意见- 并停止寻找其他实现以寻求指导（在这种情况下，您引用的那些人并没有费心做自己的功课，只是从他们中挑选了数字，嗯，你知道的） . 您可以直接访问标准- 确保您查阅最新版本，至少支持该版本，并始终处于标准之上，以便您可以适应规范的变化。
编辑感谢@ypercube 在聊天中的 ping。
顺便说一句，也许您不想首先将整个地址转储到单个列中。规范化可能表明您不想存储@hotmail.com1500 万次，因为更薄的 FK int 可以正常工作并且没有可变长度列的额外开销。您还可以将用户名标准化为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 个字符的本地部分结合时，似乎没有达成共识。这应该被世界上大多数服务器接受，但似乎违反了这个 254 个字符的限制。那么Domains，当域可以作为有效的 255 个字符的 URL 重新使用时，您是否创建了一个人为地降低电子邮件地址长度限制的表？
这个决定有几个考虑因素。首先也是最重要的是使用当前和未来对数据必须符合的必要限制的预测。varchar(1024)当您只存储不应超过 32 个字符的字符串（强调should关键字）时，您不想将每个字符串列数据类型设置为是有原因的。
如果您有某种漏洞，其中电子邮件都被修改为 255 个字符，那么您可能会对页面拆分产生长期的性能影响。这可能看起来很不寻常，而且很可能是这样，但是您需要根据业务需求调整数据的大小。就像数据库与应用程序辩论中的古老约束一样，我坚信数据类型限制和允许值也应该在数据层强制执行。
这将我引向我的下一个观点。数据库很可能只是数据层。应用层使用什么？例如，如果您有一个只能为电子邮件地址输入 80 个字符的应用程序，为什么您希望数据类型更大？企业需要回答两个问题：
只有这样你才会有你的答案。
根据定义，varchar 不是只使用保存数据所需的存储空间吗？
是和否。可变长度数据会有一种偏移量来记录它的长度。
小智 5
RFC 5321（当前的 SMTP 规范，过时的 RFC2821）指出：
用户名或其他本地部分的最大总长度为 64 个八位字节。域名或号码的最大总长度为 255 个八位字节
所以 64 + 255 + @ 符号意味着 VARCHAR(320)。你可能永远不需要这么多，但它是安全的，以防万一。