在slightly heated discussion on TDWTF中，出现了一个有关数据库中varchar列大小的问题。
例如，采用包含一个人的名字的字段(仅名字，没有姓氏)。很容易看到它不会很长。大多数人的名字少于10个字符，而少于20个字符的名字很少。如果您要创建列，例如varchar(50)，它将绝对保留您遇到的所有名字。
但是，对于大多数DBMS而言，无论您制作varchar(50)还是varchar(255)，其大小或速度都没有区别。
那么，为什么人们尝试使他们的列尽可能小？我知道，在某些情况下，您可能确实希望对字符串的长度进行限制，但多数情况并非如此。而且，只有在极少数情况下姓名非常长的人的情况下，更大的利润才有好处。
已添加:人们希望引用有关“大小或速度无差异”的声明。好。他们来了:
对于MSSQL: http://msdn.microsoft.com/en-us/library/ms176089.aspx
The storage size is the actual length of data entered + 2 bytes.
对于MySQL: http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html
L + 1 bytes if column values require 0 – 255 bytes, L + 2 bytes if values may require more than 255 bytes
我找不到Oracle的文档，也没有使用其他DBMS。但是我没有理由相信那里有什么不同。
最佳答案
我只能代表Oracle。如果输入值“SMITH”，则VARCHAR2(50)和VARCHAR2(255)会占用完全相同的空间量并执行相同的操作。
但是，通常不推荐将所有文本列都声明为VARCHAR2(4000)的原因是，列长实际上是另一个约束。约束是业务规则的数据库实现，因此，它们绝对是应该在数据库方面定义的东西。
举个例子。您可以在列上定义CHECK约束，以便其可以接受的值仅为“Y”和“N”。这使您的应用程序不必处理“y”和“n”甚至是“1”和“0”。检查约束确保您的数据符合预期的标准。然后，您的应用程序代码可以对其必须处理的数据的性质做出有效的假设。
列长度定义在同一条船上。您将某物声明为VARCHAR2(10)，因为您不希望它接受“ABC123ZYX456”的条目(无论出于何种原因!)
在澳大利亚，我将STATE列定义为varchar2(3)，因为我不希望人们输入“New South Wales”或“South Australia”。列定义几乎迫使它们输入为“NSW”和“SA”。从这个意义上讲，VARCHAR2(3)几乎与实际指定CHECK IN(“NSW”，“SA”，“VIC”等)约束的检查约束一样多。
简而言之，适当的列长是对业务规则进行编码的一种方式。它们是另一种约束形式。它们带来了约束的所有优点(并遭受许多相同的缺点)。而且它们在一定程度上确保了“适当的”约束也能提供一定程度的“数据清洁度”。
我也不赞成这样的观点，即最好将这些东西粘贴在客户端应用程序中，因为在此处进行更改更容易。您有20,000个人在使用一个应用程序，即20,000个更新。您只有一个数据库，那就是一个更新。 “更轻松地更改客户端应用程序”参数(如果为true)可能意味着数据库只是被视为一个巨大的存储桶，而所有聪明的逻辑都在客户端代码中进行处理。这是一个很大的讨论，但是由于所有RDBMS都允许您在数据库本身中定义约束等，因此很显然，至少有一个值得做的例子，就是这种基本逻辑属于后端。
关于database-design - (n)varchar列选择什么大小？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1261441/