SQL中的CHAR数据类型是否已过时？你什么时候使用它？

Question

标题几乎构成了问题。我多年没有使用过CHAR。现在，我正在对一个包含CHAR的数据库进行逆向工程，包括主键，代码等。 CHAR（30）列怎么样？

编辑： 所以普遍意见似乎是CHAR，如果对某些事情完全没问题。但是，我认为您可以设计一个不需要“这些特定事物”的数据库模式，因此不需要固定长度的字符串。使用bit，uniqueidentifier，varchar和text类型，似乎在一个良好规范化的模式中，当您使用编码的字符串值时，您将获得某种优雅。以固定长度思考，没有冒犯意味着，似乎是大型机时代的遗物（我曾经自己学过RPG II）。我相信它已经过时了，我没有听到你声称不同的令人信服的论点。

Answer 1

我使用char（n）代码，varchar（m）进行描述。 Char（n）似乎可以带来更好的性能，因为当内容大小发生变化时，数据不需要移动。

Answer 2

对于处理来说，CHAR比我熟悉的DBMS中的VARCHAR更快。它们的固定大小允许使用VARCHAR无法实现的优化。此外，CHARS的存储要求略低，因为不需要存储长度，假设大多数行需要完全或接近完全填充CHAR列。

使用CHAR（30）而不是CHAR（4）对影响（以百分比计）的影响较小。

关于使用方法，我倾向于在以下任何一种情况下使用CHAR：

• 字段通常总是接近或达到其最大长度（股票代码，员工ID等）;或
• 长度很短（小于10）。

在其他地方，我使用VARCHAR。

Answer 3

如果数据的性质决定了字段的长度，我使用CHAR。否则为VARCHAR。

Answer 4

当值的长度固定时，我使用CHAR。例如，我们基于某种算法生成代码或某些东西，该算法返回具有特定固定长度的代码，例如13。

否则，我发现VARCHAR更好。使用VARCHAR的另一个原因是，当您在应用程序中获得值时，您不需要修剪该值。在CHAR的情况下，无论值是否完全填充，您都将获得列的全长。它会被空格填充，你最终会修剪每一个值，而忘记这会导致错误。

Answer 5

对于PostgreSQL，文档指出char()在varchar()之上的存储空间没有优势;唯一的区别是它是空白填充到指定的长度。

话虽如此，我仍然使用char(1)或char(3)来表示单字符或三字符代码。我认为由于指定列应包含的类型的清晰度提供了价值，即使没有存储或性能优势。是的，我通常也使用检查约束或外键约束。除了这些情况，我通常只使用text而不是使用varchar()。同样，这是由数据库实现提供的，如果值足够大，它会自动从内联存储切换到外部存储，而其他一些数据库实现则不会这样做。

Answer 6

Char不会过时，只应在字段长度不变的情况下使用。在平均数据库中，这将是非常少的字段，主要是某些类型的代码字段，如状态缩写，如果您使用邮政编码，则是标准的2字符字段。使用字段长度可变的字符表示将进行大量修剪，这是额外的，不必要的工作，数据库应该重构。