> >What exactly is wrong about using ENUM's?
> Changing them will kill you unless you're _very_ careful.
> Using them is usually unnecessary as you could've used an ID value
> pointing to another table of values. That table can then be added to
> with no risk to your existing queries. As a contrived example:
> Employee
> ----------
> ID ... primary key
> Gender enum('male','female')
> vs.
> GenderID tinyint
>
> Gender
> ------
> ID tiny int ... primary key
> Name varchar(10)
> INSERT into Gender(Name) values ('male'),('female');
> Later, you might need:
> INSERT into Gender(Name) values ('unknown');
Is not enum forced to any of the values used when created?
We use enum extensively for 'Y' 'N' values, sort of true false.
That way the values are forced to be one or the other. So any end user has to put one
of those
values in (if we allow it in that way, though we usually force them to use a checkbox).
And its a little more viewable/understandable than 0 or 1, for the end user.
I also was under the impression that JOINs did take a little extra time/resource
rather than a direct value from the same table. We have a number of tables that
have multiple "true/false" values (one with about 50), is not joining that table
to 50 different fields not a little expensive?
Maybe we are just doing it all wrong? If we never expect the
values to be different (EVER) then is it still wrong?
Bah, sql, mysql
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
