Hi,
Jim C. Nasby wrote:
> Please go back through the original thread. The original comment was
> regarding adding an enum type that actually made sense; ie: it stored an
> int in the base table that referenced a parent table. The original
> poster was arguing that enum didn't really buy anything over doing that
> the manual method (create seperate table; fill that table with values;
> create base table with RI, and finally, make sure that everything that
> touches the base table can do mapping, or add a bunch of other stuff to
> do the mapping automatically). My argument is that simply specifying
>
> fieldname ENUM(...)
>
> is a heck of a lot easier on developers than doing all those manual
> steps, yet it still does things in the correct, normalized manner
> (unlike MySQL).
I don't want to go through the original thread, but you are probably missing a
point, MySQL manual states [1]:
==========
If you want to determine all possible values for an ENUM column, use SHOW
COLUMNS FROM tbl_name LIKE enum_col and parse the ENUM definition in the second
column of the output.
==========
Are you actually going to also implement SHOW COLUMNS blah-blah-blah? If not,
poor MySQL users will still need to rewrite their applications. They will also
need to know the name of the automagically generated table from somewhere.
[1] http://dev.mysql.com/doc/mysql/en/enum.html
