数据库字段的默认大小

部分取决于您的DBMS。有些(比如mysql 5)关心varchar(n)列的长度,而不是无限长的文本列;另一些(比如postgresql)则认为文本和varchar(n)在内部是相同的,只是在varchar(n)列上检查了长度。在PostgreSQL中编写varchar(65536)之类的东西是愚蠢的;如果您想要一个无限长的列,请选择文本并完成它。

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

根据关联的RFC,电子邮件地址的长度不能超过320个字符,因为我现在懒得查找它的号码。所以有你的电子邮件字段长度。 结果发现,smtp将字段长度限制为256个字符;由于电子邮件地址必须加括号,因此最长的有效电子邮件地址实际上是254个字符。( This page 更详细)所以 有 您的电子邮件字段长度。

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

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

加倍估计。然后加倍以适应Unicode。

具有varchar(几乎所有do)的数据库对字段的惩罚非常小,这些字段被设计为保存较长的值,但不保存。你可以利用这一点。

试着反过来考虑:我已经使用了现有的数据来获得合理的字段长度。假设您可以访问一个包含真实数据的大容量数据库,快速查询如下:

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

会给你所需要的一切。

更新:不要使用你得到的确切数字。很明显,根据你的不确定度,把它垫起来一点,除非你有一个非常大的样本集。

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

例如,姓名:varchar(70) 邮箱:varchar(200)