Comments on: Picking datatype for STATUS fields

By: Joe

Joe — Sat, 06 Dec 2008 21:31:34 +0000

Awesome article, makes me want to go and check some of my older db designs to see how I was doing them.

For some time I’ve been doing this: The status field is a TINYINT or INT(2). But to attack the problem of self documentation, I just create a table with fields, and DBAs and DB users don’t have to ask the dev team for the meaning of those numeric values. Heck, they can even make joins with this table to get an understandable query result.

What do you think of it?

By: peter

peter — Mon, 18 Aug 2008 23:43:26 +0000

Lukas,

In many cases you would see “const” join type for such tables which is very fast (because it is pre-read only once) however if it is join for each row it can get expensive even if data is in memory – join is still much slower than fetching data from the different column in same table.

By: Eric Brunson

Eric Brunson — Mon, 18 Aug 2008 20:32:37 +0000

Peter,

That’s very good to know, thank you.

By: Lukas

Lukas — Mon, 18 Aug 2008 13:12:33 +0000

Just to take an even different look. On a current project using SQL server, the application developer I am designing the schema with prefers to use lookup tables for all of this.

A lookup table behaves more or less like ENUM with a few key differences:
- Its ease to add/remove entries (even reordering is possible without having to alter the db schema
- Obviously you end up having to do joins. However the lookup tables should obviously be super small and easily fit into memory

By: peter

peter — Mon, 18 Aug 2008 00:30:57 +0000

Thanks Dave for putting it to the log buffer

By: peter

peter — Mon, 18 Aug 2008 00:24:24 +0000

Eric,

Exception is raised in case you use “strict” mode. In traditional (default) mode MySQL is generally very permissive in value storage trying to make a best fit for the value.

By: Eric Brunson

Eric Brunson — Sun, 17 Aug 2008 22:32:38 +0000

“It is also worth to note ENUM comes with couple of gotchas – first if you store value which is not allowed by ENUM list it will be always converted to ” – empty string, the additional ENUM columns can have.”

That is an implementation flaw in my opinion. It should be similar to a FK violation and raise an exception.

By: Vahur

Vahur — Sat, 16 Aug 2008 17:41:13 +0000

Nice article and especially “the 1-bit trick is a CHAR(0) NULL” from Baron Schwartz. I never thought about it like this.

By: peter

peter — Sat, 16 Aug 2008 00:39:37 +0000

Thanks Roland,

Indeed this applies to standard behavior. If you get to Strict mode it is going to be changed… but a lot of other stuff is going to change as well. In most cases I’ve seen enabling strict mode also needed a lot of minor fixes to the application to make it work

By: Roland Bouman

Roland Bouman — Fri, 15 Aug 2008 21:06:03 +0000

Hi Peter,

nice post, thanks. Found one error though:

“if you store value which is not allowed by ENUM list it will be always converted to ” – empty string”

This is the case if your sql_mode does not include STRICT_TRANS_TABLES or STRICT_ALL_TABLES (which it doesn’t by default). If it does include (or is equal to) these modes, value truncation due to inserting or updating a non-defined value will lead to a runtime error:

ERROR 1265 (01000): Data truncated for column ‘%c’ at row %r

(Do you have any benchmark data on sql modes? would be interesting to know whether there is a performance penalty involved in one of these modes, or the more encompassing TRADITIONAL mode)

Roland