SQL中的CHAR数据类型已经过时了吗？何时使用它？
SQL中的CHAR数据类型已经过时了吗？何时使用它？
标题基本上就是问题的提出。我多年来没有使用CHAR。现在，我正在逆向工程一个充斥着CHAR的数据库，用于主键、编码等等。
一个CHAR(30)的列怎么样？
编辑：
所以总体意见似乎是CHAR对于某些事情来说完全可以。然而，我认为你可以设计一个数据库模式，不需要“这些特定的事情”，因此不需要固定长度的字符串。使用位、唯一标识符、varchar和text类型，在一个良好规范化的模式中，你得到了一种优雅，而使用编码的字符串值则没有这种优雅。固定长度的思维，无意冒犯，似乎是主机时代的遗留物（我自己曾经学过RPG II）。我认为它已经过时了，而且我没有听到你们提出什么有说服力的论点来反驳这一观点。
在SQL中，使用CHAR数据类型来存储代码，使用VARCHAR数据类型来存储描述。CHAR数据类型似乎具有更好的性能，因为当内容的大小发生变化时，数据不需要移动。
然而，CHAR数据类型在现代数据库系统中逐渐过时。原因是CHAR数据类型在存储时会占用固定的空间，不管实际内容的大小。这意味着如果存储的内容不够长，CHAR字段会浪费存储空间。另外，当存储的内容长度超过CHAR字段定义的长度时，会发生截断。这可能导致数据丢失或错误。
相比之下，VARCHAR数据类型在存储时只占用实际内容所需的空间。这使得VARCHAR更加灵活和高效。另外，VARCHAR字段可以存储不同长度的内容，而不会引发截断问题。
因此，当我们需要存储不确定长度的数据时，应该优先考虑使用VARCHAR数据类型。只有在特定情况下，我们才会使用CHAR数据类型。例如，当我们需要存储固定长度的代码时，CHAR数据类型可能会提供更好的性能。
，尽管CHAR数据类型在某些情况下可以提供更好的性能，但在现代数据库系统中，VARCHAR数据类型更加常用和推荐。我们应该根据具体需求来选择合适的数据类型，以确保数据的完整性和高效性。
CHAR数据类型在SQL中是否过时？何时使用它？
CHAR在我熟悉的数据库管理系统中，仍然比VARCHAR更快。它们的固定大小可以进行一些无法在VARCHAR中进行的优化。此外，由于不需要存储长度，所以CHAR的存储要求稍微低一些，假设大多数行都需要完全或接近完全地填充CHAR列。
对于CHAR(30)而言，这种影响（以百分比计算）较小，而对于CHAR(4)而言，影响较大。
至于使用情况，我倾向于在以下情况下使用CHAR：
- 字段通常始终接近或达到其最大长度（库存代码、员工ID等）；
- 长度较短（小于10）。
其他情况下，我使用VARCHAR。
此外，如果一个VARCHAR使用4个字节来存储长度，并且所有行浪费的空间少于4个字节，那么CHAR更好，这就是“接近”的意思。长度为10的选择只是我个人的偏好，因为CHAR更快，每行浪费10个字节是无关紧要的（在我的平台上）。
关于<10的建议，我不同意。如果数据元素的长度是固定的，我会使用CHAR。如果数据可能是3个字节，也可能是8或9个字节，为什么要将其定义为char(9)并浪费所有那些空间（而且处理一些DBMS在CHAR上添加的填充）？
不过，持不同意见也是可以的 🙂 如我所说，这是我的个人偏好，在我的世界（大型机）中，我认为磁盘空间比原始速度（在某种程度上）更不重要。
