Comments on: MySQL's "enum" datatype is a good thing http://www.databasesandlife.com/mysqls-enum-datatype-is-a-good-thing/ Adrian Smith's blog Wed, 14 Jul 2010 07:18:51 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Peter Morris http://www.databasesandlife.com/mysqls-enum-datatype-is-a-good-thing/comment-page-1/#comment-1933 Peter Morris Mon, 05 Jan 2009 13:31:33 +0000 http://www.databasesandlife.com/?p=239#comment-1933 Michael C, I think it is you who has missed the point :-) You use a lookup table if the meaning is purely illustrative for the user. E.g. moods Happy, Sad, Angry but if an application logic needs to function differently depending on the state and the user cannot define the states, as in a purchase order Raising, Raised, Cancelled then this should be defined as an enum and not a data table that contains an additional numeric column with a "special value" in it. Whether the enum belongs in the DB as an enum or not is not my argument, it's just that your comment about people being too lazy is not accurate. -- Pete ==== http://mrpmorris.blogspot.com http://www.capableobjects.com - Think domain, not database Michael C, I think it is you who has missed the point :-)

You use a lookup table if the meaning is purely illustrative for the user. E.g. moods

Happy, Sad, Angry

but if an application logic needs to function differently depending on the state and the user cannot define the states, as in a purchase order

Raising, Raised, Cancelled

then this should be defined as an enum and not a data table that contains an additional numeric column with a “special value” in it.

Whether the enum belongs in the DB as an enum or not is not my argument, it’s just that your comment about people being too lazy is not accurate.

–
Pete
====
http://mrpmorris.blogspot.com
http://www.capableobjects.com – Think domain, not database

]]> By: Michael C http://www.databasesandlife.com/mysqls-enum-datatype-is-a-good-thing/comment-page-1/#comment-1932 Michael C Mon, 05 Jan 2009 13:05:21 +0000 http://www.databasesandlife.com/?p=239#comment-1932 I think you've completely missed the point. The question is not whether enums compared to no enums is a good thing (obviously it's better to have greater constraint). The real question is whether it's better to use an enum or a another table to store the list of these enum values. To follow your invoice example above, you would have an invoice table and, say, an InvoiceState table which listed all the possible states of the invoice. You would then have a foreign key joining the 2 tables. The advantage to this is that if you need to add further data to this InvoiceState table then you could (for example, you could have shortname, longname for the enum values etc). Using an enum data type in a database is just a poor substite for those too lazy to create a table. I think you’ve completely missed the point. The question is not whether enums compared to no enums is a good thing (obviously it’s better to have greater constraint). The real question is whether it’s better to use an enum or a another table to store the list of these enum values. To follow your invoice example above, you would have an invoice table and, say, an InvoiceState table which listed all the possible states of the invoice. You would then have a foreign key joining the 2 tables. The advantage to this is that if you need to add further data to this InvoiceState table then you could (for example, you could have shortname, longname for the enum values etc). Using an enum data type in a database is just a poor substite for those too lazy to create a table.

]]>