我一直在将 MySQL 数据库迁移到 Pg (9.1)，并通过在 Pg 中创建新数据类型，然后将其用作列定义来模拟 MySQL ENUM 数据类型。我的问题——我可以使用 CHECK CONSTRAINT 代替吗？ MySQL ENUM 类型被实施以强制行中的特定值条目。这可以通过检查约束来完成吗？如果是，会更好（或更糟）吗？
【问题讨论】：
在我看来，给定一组相同的值
当然，还有很多其他参数可能会影响您的决策过程（通常是内置运算符不可用的事实），但我认为这两个是最普遍的。
【讨论】：
根据此处的 cmets 和答案，以及一些初步研究，我有以下摘要可提供给 Postgres-erati 的 cmets。非常感谢您的意见。
有三种方法可以限制 Postgres 数据库表列中的条目。考虑一个存储“颜色”的表，您只希望“红色”、“绿色”或“蓝色”作为有效条目。
枚举数据类型
CREATE TYPE valid_colors AS ENUM ('red', 'green', 'blue');
CREATE TABLE t (
color VALID_COLORS
);
优点是类型可以定义一次，然后根据需要在尽可能多的表中重用。标准查询可以列出 ENUM 类型的所有值，并可用于制作应用程序表单小部件。
SELECT n.nspname AS enum_schema,
t.typname AS enum_name,
e.enumlabel AS enum_value
FROM pg_type t JOIN
pg_enum e ON t.oid = e.enumtypid JOIN
pg_catalog.pg_namespace n ON n.oid = t.typnamespace
WHERE t.typname = 'valid_colors'
enum_schema | enum_name | enum_value
-------------+---------------+------------
public | valid_colors | red
public | valid_colors | green
public | valid_colors | blue
缺点是，ENUM 类型存储在系统目录中，因此需要进行上述查询才能查看其定义。查看表定义时，这些值不明显。而且，由于 ENUM 类型实际上是一种独立于内置 NUMERIC 和 TEXT 数据类型的数据类型，因此常规的数字和字符串运算符和函数对其不起作用。所以，一个人不能做这样的查询
SELECT FROM t WHERE color LIKE 'bl%';
检查约束
CREATE TABLE t (
colors TEXT CHECK (colors IN ('red', 'green', 'blue'))
);
两个优点是，一是“所见即所得”，即列的有效值直接记录在表定义中，二是所有原生字符串或数字运算符都可以工作。
外键
CREATE TABLE valid_colors (
id SERIAL PRIMARY KEY NOT NULL,
color TEXT
);
INSERT INTO valid_colors (color) VALUES
('red'),
('green'),
('blue');
CREATE TABLE t (
color_id INTEGER REFERENCES valid_colors (id)
);
本质上与创建 ENUM 类型相同，不同之处在于本机数字或字符串运算符可以工作，并且无需查询系统目录即可发现有效值。需要连接才能将color_id 链接到所需的文本值。
【讨论】：
正如其他答案所指出的，检查约束存在灵活性问题，但在整数 id 上设置外键需要在查找期间加入。为什么不直接使用允许的值作为引用表中的自然键？
从punkish's answer调整架构：
CREATE TABLE valid_colors (
color TEXT PRIMARY KEY
);
INSERT INTO valid_colors (color) VALUES
('red'),
('green'),
('blue');
CREATE TABLE t (
color TEXT REFERENCES valid_colors (color) ON UPDATE CASCADE
);
值与检查约束情况一样内联存储，因此没有连接，但可以轻松添加新的有效值选项，并且可以通过ON UPDATE CASCADE 更新现有值实例（例如，如果决定“红色”实际上应该为“红色”，相应地更新valid_colors，更改会自动传播）。
【讨论】：
外键与检查约束的一大缺点是任何报告或 UI 显示都必须执行连接才能将 id 解析为文本。
在小型系统中，这没什么大不了的，但如果您在 HR 或类似系统上工作，其中包含非常多的小型查找表，那么这可能是一个非常大的问题，因为为了获取文本而发生了大量的连接。
我的建议是，如果值很少且很少更改，则对文本字段使用约束，否则对整数 id 字段使用查找表。
【讨论】：
我希望有人能从 PostgreSQL 数据库方面给出一个很好的答案，说明为什么一个可能比另一个更可取。
从软件开发人员的角度来看，我稍微倾向于使用检查约束，因为 PostgreSQL 枚举需要在您的 SQL 中进行强制转换才能进行更新/插入，例如：
INSERT INTO table1 (colA, colB) VALUES('foo', 'bar'::myenum)
其中“myenum”是您在 PostgreSQL 中指定的枚举类型。
这当然使 SQL 不可移植（这对大多数人来说可能没什么大不了的），但也是您在开发应用程序时必须处理的另一件事，所以我更喜欢使用 VARCHAR（或其他典型的原语） ) 带有检查约束。
顺便说一句，我注意到 MySQL 枚举不需要这种类型的转换，所以根据我的经验，这是 PostgreSQL 特有的。
【讨论】：
::myenum 后缀未在当前 postgres 文档中提及：postgresql.org/docs/current/static/datatype-enum.html
PostgreSQL 有enum types，可以正常工作。我不知道枚举是否比约束“更好”，它们都可以工作。
【讨论】：