SQL 中的 CHAR 数据类型是否已过时?你什么时候使用它? [英] Is the CHAR datatype in SQL obsolete? When do you use it?

问题描述

标题几乎是问题的框架.我已经好几年没用过 CHAR 了.现在，我正在对一个全是 CHAR 的数据库进行逆向工程，用于主键、代码等.CHAR(30) 列怎么样?

The title pretty much frames the question. I have not used CHAR in years. Right now, I am reverse-engineering a database that has CHAR all over it, for primary keys, codes, etc. How about a CHAR(30) column?

因此，普遍的看法似乎是 CHAR 如果对某些事情完全没问题.但是，我认为您可以设计一个不需要这些特定事物"的数据库模式，因此不需要固定长度的字符串.使用 bit、uniqueidentifier、varchar 和 text 类型，似乎在一个规范化的模式中，您会获得某种优雅，而这是使用编码字符串值时所没有的.从固定角度思考，没有冒犯的意思，似乎是大型机时代的遗物(我自己学过 RPG II).我相信它已经过时了，而且我没有听到你声称的令人信服的论点.

So the general opinion seems to be that CHAR if perfectly fine for certain things. I, however, think that you can design a database schema that does not have a need for "these certain things", thus not requiring fixed-length strings. With the bit, uniqueidentifier, varchar, and text types, it seems that in a well-normalized schema you get a certain elegance that you don't get when you use encoded string values. Thinking in fixed lenghts, no offense meant, seems to be a relic of the mainframe days (I learned RPG II once myself). I believe it is obsolete, and I did not hear a convincing argument from you claiming otherwise.

推荐答案

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

Where the nature of the data dictates the length of the field, I use CHAR. Otherwise VARCHAR.

这篇关于SQL 中的 CHAR 数据类型是否已过时?你什么时候使用它?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！