SQL：ENUM 与一对多关系的优点？

我很少看到 ENUM 数据类型在野外使用；开发人员几乎总是只使用如下所示的辅助表：

CREATE TABLE officer_ranks (
id int PRIMARY KEY
,title varchar NOT NULL UNIQUE);
INSERT INTO officer_ranks VALUES (1,'2LT'),(2,'1LT'),(3,'CPT'),(4,'MAJ'),(5,'LTC'),(6,'COL'),(7,'BG'),(8,'MG'),(9,'LTG'),(10,'GEN');

CREATE TABLE officers (
solider_name varchar NOT NULL
,rank int NOT NULL REFERENCES officer_ranks(id) ON DELETE RESTRICT
,serial_num varchar PRIMARY KEY);

但同样的事情也可以使用用户定义的类型/ENUM 来显示：

CREATE TYPE officer_rank AS ENUM ('2LT', '1LT','CPT','MAJ','LTC','COL','BG','MG','LTG','GEN');
    
CREATE TABLE officers (
solider_name varchar NOT NULL
,rank officer_rank NOT NULL
,serial_num varchar PRIMARY KEY);

（示例使用 PostgreSQL，但其他 RDBMS 也有类似的语法）

我认为使用 ENUM 的最大缺点是从应用程序内部更新更加困难。这也可能会让习惯于将 SQL DB 简单地用作位存储桶的缺乏经验的开发人员感到困惑。

假设信息大部分是静态的（工作日名称、月份名称、美国陆军军衔等），使用 ENUM 有什么优势吗？

使用 PostgreSQL 显示示例，但其他 RDBMS 具有类似的语法

这是不正确的。它不是 ISO/IEC/ANSI SQL 要求，因此商业数据库不提供它（您应该提供查找表）。城镇的小端实施各种“额外”，但不执行城镇大端的更严格要求或咕噜声。

我们也没有将 ENUM 作为数据类型的一部分，这是荒谬的。

ENUM 的第一个缺点是它是非标准的，因此不可移植。

ENUM 的第二大缺点是数据库是封闭的。可在数据库上使用的数百个报告工具（独立于应用程序）无法找到它们，因此无法预测名称/含义。如果您有一个普通的标准 SQL 查找表，那么这个问题就可以消除。

第三个是，当你改变值时，你必须改变DDL。在普通标准 SQL 数据库中，您只需在查找表中插入/更新/删除一行即可。

最后，您无法轻松获得 ENUM 的内容列表；你可以使用查找表。更重要的是，您有一个向量可以用来执行任何维度事实查询，从而无需从大型事实表和 GROUP BY 中进行选择。