Re: Dealing with ENUM fields

Will there ever be 5 specials categories? 6? I like enums for strings, but for more complex sites I go with a separate table for even 4 categories. I don't actually know what happens if you change "lunch" to "pre-dinner" on the enum column -- does everything remain as enum selection #1 and change to "pre-dinner" or do things get messed up? If you already have a categories table, just add one more column -- "specials" which is a tinyint default 0 -- those 4 categories are set to non-zero (or 1 (that's one)). This needs no more tables, no specialized enums, and you are reusing an existing table structure. I like that better. But either way works. ALSO NOTE! If you use enums for numbers, such as '0', '1', they are treated as strings. I don't believe you can make an enum treat a number as a numeric. ALTER TABLE reviewdates ADD asdf ENUM( 0, 1 ) NOT NULL You have an error in your SQL syntax near '0,1) NOT NULL' at line 1 Peter On Tue, 3 Jun 2003, Becoming Digital wrote: > This is for another menu project that I'm working on. The restaurant has a > large list of daily specials, all of which fit into one of four categories > (lunch, dinner, pizza, dessert). Because the data will never mix (no need for > joins or unions), I wanted to keep the specials categories separate from the > regular menu item categories. Because there are only four specials categories > and they are static, I thought ENUM would work best. Your opinions? > > Edward Dudlik > Becoming Digital > www.becomingdigital.com --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@purplecow.com http://www.purplecow.com/ ---------------------------------------------------------------------------