On Thu, Apr 24, 2008 at 11:04:10AM -0500, D. Dante Lorenso wrote:
>
> Or, here's another way to look at it ... make it easier to modify ENUM
> datatypes because we all know that you will eventually need that feature
> whether you males, females, and unknowns think so or not.
Well, heck, why don't you just store your data in one infinitely wide table
with 10,000 nullable fields? Then you can complain about the storage or
performance implications.
If you are devoted to an enum datatype, then you don't want to normalise
your data further. With an incredibly small number of exceptions, I'd argue
that means one of two things: either it doesn't need normalisation, in
which case a relational database is the wrong tool for this job; or else it
does need normalisation, but you don't understand how relational databases
work well enough to do it properly. [Later: on re-reading this paragraph, I
thought of a third possibility: that you're violating the first rule of
optimisation.]
The first time I encountered them, I thought enums were a filthy,
ill-conceived answer to a problem that didn't exist, implemented by people
who didn't understand relational databases. With considerably more
experience under my belt than then, I say now that my original estimation
was too kind.
I do see what someone says upthread: if you have a special case where the
storage saving adequately offsets the maintenance cost, this might be worth
it. But if you've really analysed your case that carefully, and understand
the costs (i.e. you won't carp later when changing is expensive) you already
know what you're doing.
Otherwise, don't use enums. They should be marked (like char(), IMO) in the
manual as, "Warning: you probably don't want to use this datatype. Go think
some more."
A
