数据库字段的默认大小

在一定程度上,这取决于你的DBMS。有些数据库,比如MySQL 5,关心VARCHAR(n)列的长度,而不是无限长的TEXT列;其他一些,如PostgreSQL,认为TEXT和VARCHAR(n)在内部是相同的,除了在VARCHAR的(n)列上检查长度。在PostgreSQL中编写类似VARCHAR(65536)的东西是愚蠢的;如果你想要一个长度不受限制的列,请选择TEXT并完成它。

当然,有时试图存储太长的值会破坏你的布局,或者允许有人通过选择没有空格的长名称来滥用系统(例如)。通常,我对用户名字段所做的就是选择一个上限长度,这样任何想要更长用户名的人都会试图制造麻烦;64个字符是一个很好的舍入值,似乎效果很好。对于真实姓名和地址(不像用户名那样经常显示给用户),你会想使用更长的东西。您需要一个足够大的值,以便它可以接受任何有效的输入,但不要太大,以至于有人可以在字段中插入一个千兆字节长的字符串来攻击您的系统。1024个字符是相当合理的:1k是一个足够小的文本,可以轻松使用,是一个整数,比任何正常的地址行或名称都大。

根据相关RFC(我现在懒得查找其编号),电子邮件地址不能超过320个字符。这就是你的电子邮件字段长度。 原来SMTP将字段长度限制为256个字符;由于电子邮件地址必须用括号括起来,因此最长的有效电子邮件地址实际上是254个字符。 ( This page 更详细地说。)所以

密码应 永不 以明文形式存储,因此您的密码字段应该是一个字节数组或BLOB类型,其长度足以存储您正在使用的哈希函数的输出(或者对于SRP-6a等更高级的方案,使用的加密组的最大元素)。

我喜欢16、32、64、128或256

加倍你的估计。然后加倍努力以适应unicode。

试着反向思考:我使用现有数据来获得合理的字段长度。假设您可以访问一个充满真实数据的大型数据库,快速查询如下:

SELECT MAX(LEN(lastname)) FROM dbo.MyDatabase

会给你你需要的一切。

更新:不要使用你得到的确切数字。显然,除非你有一个非常大的样本集,否则要根据你的不确定性稍微增加一点。

我倾向于考虑一个字段的值可能有多长,然后加倍以确保安全。

例如,名称:varchar(70) 电子邮件:varchar(200)