字符列长度

诸如URL和电子邮件地址之类的RFC可能是有用的。URL有2083个字符的限制,而电子邮件地址的最大长度为320个字符(名称为64个字符,@为1个字符,域为255个字符)。

一般来说,对于任何存储用户数据的东西,我都会犯“太长”的错误。对于内部使用,我尽量限制。我通常用50表示键,255表示描述,等等。除非你在做搜索或其他事情,否则你不会看到对性能有多大的影响,所以很多选择都取决于你的个人喜好。

简而言之:

1. 存在此数据(URL、电子邮件地址等)的规范:请精确
2. 用户数据:长时间查找名称等内容,对注释文本等内容设置合理的限制
3. 内服:随遇而安

通常,我会考虑我能想到的字段最长数据项的预期长度,然后通常将该长度的10-20%作为起点,除非我知道数据有一个指定的限制(例如,邮政编码有一个指定的长度),并且我使用它。如果长度在一个硬限制(它必须是该长度而不是其他,我使用一个char数据类型,否则我使用varchar或nvarchar作为字符串数据。

至少在mysql中,varchar字段的开销是一个字节(最大宽度可达255字节),或者是两个字节(任何较大的最大宽度)。因此,一个好的经验法则是在不希望数据超过255字节时使用varchar(255),或者在其他地方使用varchar(65535)。

当然,如果您希望对数据有一个真正的硬限制,那么您可能希望在列定义中设置一个限制,作为第二级数据验证(但是,如果该限制太远而导致数据库错误,则应将其视为更高级别的错误)。

来源: http://dev.mysql.com/doc/refman/6.0/en/char.html

对于一个网址,我会咨询RFC的网址。名字和姓氏我一般都用100个字符——正如你所说,这并不重要,因为(n)varchar只占用它需要的空间。

我倾向于做的事情:

• 我通常使用nvarchar而不是varchar来命名,因为许多名称需要特殊字符。
• 我确保无论在数据库中选择什么长度,我都会在ui中强制执行。

你想优化什么?正如所指出的,一个普通的varchar在成本上没有太大的差别,所以不值得为此付出太多努力。您可能关心的另一个原因是某种验证规则,在这种情况下,您需要弄清楚是什么决定了字段值是否有效。然后应用它。

谨慎地开始,YelPut守旧,可以让你以后扩展,以巨大的长度开始可以引入性能和使用的未知因素,并且可能会使以后很难修剪。

你会有很多很多很多你不确定的专栏吗?以后改变它们会是一项可怕的任务吗?如果不保守,如果达到了极限,就可以扩展——记住不要让这些约束散布在代码中;尽可能集中它们,并在需要时强制它们。

试着选择一个比你期望的要长的长度,但不是完全不可能。如果你认为25是一个合理的领域,那么把它设为50;如果150看起来是对的,那么把它设为200。

通常我们使用NVARCHAR(100)来命名,255用于URL或其他可以长的字段(这些通常只是域名,而不是站点特定页面/资源的完整URL)。我们的大型机也有类似的限制,而且每年我们都会进行一些字段扩展——但我们预计到了这一点,修改它们也没什么大不了的。