sql - 使用数据类型 "text"存储字符串有什么缺点吗？

Question

根据PostgreSQL Documentation ，它们支持 3 种数据类型的字符数据:

character varying(n), varchar(n)  variable-length with limit
character(n), char(n)             fixed-length, blank padded
text                              variable unlimited length

在我的应用程序中，我遇到了一些令人不快的场景，其中插入/更新查询失败，因为要插入的所需文本超过 varchar(n) 或 char(n) 限制。

对于这种情况，将这些列的数据类型更改为text 就足够了。

我的问题是:

• 如果我们将每个字符存储列的数据类型概括并更改为text，在性能/内存方面是否有任何缺点？
• 如果数据类型为 text 的列每次存储 10 个或更少的字符，我应该选择 text 还是 varchar(10)？
• 如果我选择 text 有什么缺点？

Answer 1

一般来说，使用text没有缺点在性能/内存方面。相反:text 是最优的。其他类型或多或少有相关的缺点。 text 字面意思是 "preferred" type among string types在 Postgres 类型系统中，这会影响函数或运算符类型解析。

特别是，never use char(n) ( character(n) 的别名)，除非您知道自己在做什么。 char 或 character 只是 character(1) 的缩写，所以都是一样的。内部名称是 bpchar(代表“空白字符”)。该类型只是为了与旧代码和标准兼容。现在已经没什么意义了，浪费内存而且很可能会引起麻烦:

• Compare varchar with char
• String field length in Postgres SQL

您可以使用 varchar(n)带有长度修饰符(character varying(n) 的别名)。但是 varchar(255) typically indicates a misunderstanding从其他 RDBMS 继承而来，它可能是性能的局部最优值。在 Postgres 中，长度修饰符 (255) 没有特殊含义，很少有意义。

• Should I add an arbitrary length limit to VARCHAR columns?

当稍后尝试更改 varchar(n) 的长度修饰符时，旧版本会导致各种问题。其中大部分在现代 Postgres 中已得到缓解，但 text 或 varchar (character varying 的别名)没有长度说明符(而是 CHECK constraint)从未遇到过任何这些问题。

CHECK 约束与依赖 View 、函数、FK 约束等依赖于列类型的依赖一样快并且不太可能引起问题。它不仅可以执行最大字符长度 - 可以放入 bool 表达式的任何内容。见:

• Change PostgreSQL columns used in views

最后还有"char" (带双引号):用作廉价内部枚举类型的单个 ASCII 字母的 1 字节数据类型。

在 Postgres 中，除了 text 之外，我很少使用任何东西作为字符数据。