我想从Postgres 文档中询问这个片段关于varchar(n)类型的含义：
短字符串（最多 126 个字节）的存储要求是 1 个字节加上实际字符串，其中包括字符情况下的空格填充。较长的字符串有 4 个字节的开销而不是 1 个字节。
假设我有一个varchar(255)字段。现在，以下声明：
我经常看到人们谈论"char"。我从来没有用过它。它在文档中定义为，
“char”类型（注意引号）与 char(1) 的不同之处在于它只使用一个字节的存储空间。它在系统目录中作为一种简单的枚举类型在内部使用。
并进一步，
"char" 1 byte single-byte internal type
那么，如果它是一个字节，那么域是什么，您将如何使用它？它是签名的还是未签名的？在@Erwin Brandstetter 的这篇文章中，他对此进行了阐述，但我仍然感到困惑。他正在使用ascii()and chr()，并提供了这个
SELECT i
, chr(i)::"char" AS i_encoded
, ascii(chr(i)::"char") AS i_decoded
FROM generate_series(1,256) i;
这在 10 点到 11 点之间做一些非常奇怪的事情。
i | i_encoded | i_decoded
-----+-----------+-----------
...
8 | \x08 | 8
9 | | 9
10 | +| 10
| | -- WTF is going on here.
11 | \x0B | 11
12 | \x0C | 12 …我计划将包含更多 1000 万条记录的 CSV 加载到 PostgreSQL v12.1，其中一列具有“分类”值，因此为其创建枚举类型似乎是一个不错的选择，但它包含 208 个类别。
最短的字段为 2，最长的字段为 11 个字符。所有字段的平均值为 2.4。字符编码是 UTF8，但所有字符都是 ASCII。
我应该使用enumerated或varchar哪种类型？
我丢弃char是因为官方 PostgreSQL 文档说明了有关char、varchar和text 的以下内容：
提示：这三种类型之间没有性能差异，除了使用空白填充类型时增加了存储空间，以及在存储到长度受限列时需要额外的一些 CPU 周期来检查长度。虽然 character(n) 在其他一些数据库系统中具有性能优势，但在 PostgreSQL 中没有这样的优势；事实上 character(n) 通常是三个中最慢的，因为它有额外的存储成本。在大多数情况下，应改用文本或字符变化。
PostgreSQL 中的枚举值在磁盘上占用4 个字节（请参阅 8.7.4. 实现细节）。考虑到这一点和使用enum类型的2.4 平均字符串长度会导致磁盘使用率略高（PostgreSQL 中的短字符串需要一个额外的字节磁盘空间）。我仍然有一种直觉，即使用 enum 是更好的选择，因为它的实现使许多针对它的操作更快。
smallint类型和bool存储布尔值的类型有什么区别？
这个问题出现在对地理信息系统堆栈交换问题的评论中。
一个配置文件可以有多种配置文件类型。该配置文件可以有许多字段，这些字段都与查找表相关联。某些字段可以有多种选择。
\n\nprofile -> profile_date -> one relationship status, one zodiac, many languages, many countries traveled, many cuisines, many activities, ...\n\nprofile -> profile_network -> one company, one school, ...\n\nprofile -> ...\n字段的查找表如下所示：
\n\nid type\n1 \xe2\x99\x88 ARIES\n2 \xe2\x99\x89 TAURUS\n3 \xe2\x99\x8a GEMINI\n4 \xe2\x99\x8b CANCER\n5 \xe2\x99\x8c LEO\n6 \xe2\x99\x8d VIRGO\n7 \xe2\x99\x8e LIBRA\n8 \xe2\x99\x8f SCORPIO\n9 \xe2\x99\x90 SAGITTARIUS\n10 \xe2\x99\x91 CAPRICORN\n11 \xe2\x99\x92 AQUARIUS\n12 \xe2\x99\x93 PISCES\n如果该字段是单个选择，我们将加入查找表，然后就完成了。
\n\n-> profile_date (zodiac_type_id) -> zodiac_type.id\n如果字段是多项选择，则中间有一个用于多对多的联接表。
\n\n-> profile_date -> (profile_date_id) profile_date_languages (language_type_id) -> language_type.id\n