Luc Foisy wrote:

We use enum extensively for 'Y' 'N' values, sort of true false.
That way the values are forced to be one or the other. So any end user has to put one of those values in (if we allow it in that way, though we usually force them to use a checkbox). And its a little more viewable/understandable than 0 or 1, for the end user.

True enough, and I use enums for two-valued options myself quite often enum('false','true') for example, makes a good replacement for bool. However, you must remember to always do them in the same order and not alter it to enum('true','false') by accident and end up flipping all the data in your table.

I also was under the impression that JOINs did take a little extra time/resource rather than a direct value from the same table.

They do, but I've found it negligable so far. The joined table with only 3 or 4 values in it should sit in memory forever, and the index would be as big as the table if you bothered :).

We have a number of tables that have multiple "true/false" values (one with about 50), is not joining that table to 50 different fields not a little expensive?

Again, YMMV and I do this too. I'm just saying that for most things that people enum (colours of vehicles, brands of product, shipping company, ...) it just shouldn't be done. Its unfortunately familiar to C programmers who go "I know how to use that" (I'm a C programmer myself) and JOINs don't come naturally to.

Maybe we are just doing it all wrong? If we never expect the values to be different (EVER) then is it still wrong?

According the the SQL specs, its not wrong at all, of course. Its just IMHO (and a few others', I'd bet) that you should avoid it unless its obviously ok. Remember to document somewhere that you always use ('false','true') or vice versa so that if data needs to be rebuilt, everyone knows which value 0 stands for and which one 1 stands for. From C experience, I always put false first.

--
Michael T. Babcock
C.T.O., FibreSpeed Ltd.
http://www.fibrespeed.net/~mbabcock



---------------------------------------------------------------------
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

Reply via email to