根据PostgreSQL 文档，它们支持 3 种字符数据数据类型：
character varying(n), varchar(n) variable-length with limit
character(n), char(n) fixed-length, blank padded
text variable unlimited length
在我的应用程序中，我遇到了一些令人不快的情况，其中插入/更新查询失败，因为要插入的所需文本超出了varchar(n) or char(n) limit.
对于这种情况，将此类列的数据类型更改为text够了。
我的问题是：
- 如果我们概括并将每个字符存储列的数据类型更改为
text，在性能/内存方面有什么缺点吗？
- 如果列的数据类型
text每次存储 10 个或更少的字符，我应该选择吗text or varchar(10)?
- 如果我去
text有什么缺点？
一般来说，有no使用的缺点text在性能/内存方面。相反：text是最优的。其他类型或多或少都有相关的缺点。text从字面上看就是字符串类型中的“首选”类型在 Postgres 类型系统中，这可能会影响函数或运算符类型解析。
尤其，never使用char(n)罢工>（别名为character(n)罢工>），除非你知道自己在做什么。char or character只是缩写character(1)，所以都一样。内部名称是bpchar（代表“空白填充字符”）。该类型只是为了与旧代码和标准兼容。如今它已经没有什么意义了，浪费内存并且可能会引起麻烦：
- 比较 varchar 和 char
- Postgresql 中的字符串字段长度
您可以使用varchar(n)带长度修饰符（别名为character varying(n)). But varchar(255) 通常表示误解从其他 RDBMS 继承而来，它可能是性能的局部最佳值。在Postgres中，长度修饰符(255)没有特殊意义，也很少有意义。
旧版本在尝试更改长度修饰符时会导致各种问题varchar(n)之后。其中大部分问题在现代 Postgres 中已经得到缓解，但是text or varchar（别名为character varying）没有长度说明符（和CHECK约束相反）从未遇到过任何这些问题。
A CHECK约束同样快，并且不太可能对依赖于列类型的视图、函数、FK 约束等造成麻烦。它不仅可以强制执行最大字符长度 - 您可以放入布尔表达式中的任何内容。看：
最后，还有"char"（带双引号）：用作廉价内部枚举类型的单个 ASCII 字母的 1 字节数据类型。
我很少使用除此之外的任何东西text用于 Postgres 中的字符数据。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
