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
