I agree entirely. SETS and ENUMS should be avoided by any normal user (frankly, I think they should be deprecated). They are not portable and it's just horrific to be changing data with an ALTER statement.
Foreign Key relationships (even if they aren't real as in standard MySQL) are the way to go. Get InnoDB and use foreign keys before it's too late and you're stuck with a hodge podge system. > -----Original Message----- > From: Harald Fuchs [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 16, 2002 11:39 AM > To: [EMAIL PROTECTED] > Subject: Re: more about using sets > > > In article <[EMAIL PROTECTED]>, > David T-G <[EMAIL PROTECTED]> writes: > > > Hi, all -- > > I'm still trying to get a good handle on how sets can be > useful to me. I > > have three scenarios so far. > > > 1) A set of states (US Mail type, not turing type :-) > > I can pick from the list of states when entering address data, and > > storing the set entry should take less space than storing > even a 2-char > > string. > > > 2) A set of ccard types (MC, Visa, AmEx) > > It's easy to have a pick list to avoid misspellings and such > > > 3) A set of pay scale levels (master, journeyman, > apprentice, intern) > > Each staff member needs to be at a certain scale so that > the software > > knows how much to pay him or her per session. We don't > want to make up > > pay levels that aren't in our list. > > > For each of these, is a set the way to go, and is it saving > me anything? > > > In the third case, I want to restrict the level in the > personnel table to > > one of the defined levels. Do I just use a set in the > field definition > > and then list from there (and then it gets messy if we add > a new level) > > or do I create a "jobscalelevels" table and define the > levels in there > > and then set the personnel.level field to match and forget > about the idea > > of a set? > > I avoid SETs whenever possible - i.e. always unless > storage/performance is extremely important. > They give you nothing which you can't do with a separate value table > and foreign keys, but they compromize portability. > --------------------------------------------------------------------- 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
