After having suffered through the consequences of "type" enums on MySQL, and see some things go through a long life that used "enums" in the database (in multiple different databases, include Postgres), I'm not convinced that either of these are the right choice for representing enumerations. The string with check constraint seems dumb if for no other reason than if the table that uses it winds up having many rows, you're basically burning up lots of extra space for arguably no reason, and if you ever have to alter the name of an enum (or something similar), that update is going to be really expensive.<p>I think the "right" choice for enums probably looks a little more like:<p><pre><code> CREATE TABLE myEnum(
enumID SERIAL NOT NULL PRIMARY KEY,
enumName TEXT UNIQUE NOT NULL,
-- enum description or other metadata columns here.
);
CREATE TABLE foo(
...
associatedEnumID INTEGER NOT NULL REFERENCES myEnum(enumID),
...
);
</code></pre>
I think this has the benefit of being space efficient like the native typed enum, while being relatively flexible (easy to change names, add new enum values, add data about the enum itself, etc.)