Adam, > 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.
To add some more to this discussion, a customer of ours is having problems with something as simple as male/female coding in databases. This attribute is coded as "m/f", "1/0", "true/false", etc. What's making it a real big problem is, that it's coded in table _structures_ instead of in relational lookup tables. The smart guy who put ENUM (and SET, if that's ANSI-SQL) into the SQL standard should be punished with a life sentence, cleaning up our customer's mess ;-) Regards, -- Stefan Hinz <[EMAIL PROTECTED]> CEO / Geschäftsleitung iConnect GmbH <http://iConnect.de> Heesestr. 6, 12169 Berlin (Germany) Telefon: +49 30 7970948-0 Fax: +49 30 7970948-3 ----- Original Message ----- From: "Adam Nelson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, December 16, 2002 10:47 PM Subject: RE: more about using sets > 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 > --------------------------------------------------------------------- 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
