Three reasons to keep a table of card types:
1. Generally as an added check, you ask the user to specifiy the card type,
then ask for the number. If that card type check is data-driven, you will
need less code modification over time.
2. Once MySQL comes to support stored procs, there is a case to
Paul DuBois wrote:
I just tried this script:
[ ... ]
I don't see anything getting flipped.
Wow, I'm impressed :-). I've not actually tried this myself (as it has
been a known bug in at least other db software). Good to know that
MySQL has no such problem.
Now testing:
create table test
Anderson, Alan R wrote:
Isn't the card type a piece of derived data? You should never have to enter it directly; it's computable from (the first digit(s) of) the card number.
Also note, the type of card isn't a SET option at all (it would be an
ENUM) and if its used as a foreign-key relatio
> From: David T-G [mailto:[EMAIL PROTECTED]]
> ...I still have to figure
> out how to make sure that our credit card types and skill levels don't
> get corrupted (MC, MasterCard, mastercard, ...), but I guess that gets
> enforced in the software interface, right?
Isn't the card type a piece of der
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/un
> >What exactly is wrong about using ENUM's?
> Changing them will kill you unless you're _very_ careful.
> Using them is usually unnecessary as you could've used an ID value
> pointing to another table of values. That table can then be added to
> with no risk to your existing queries. As a cont
Luc Foisy wrote:
What exactly is wrong about using ENUM's?
Changing them will kill you unless you're _very_ careful.
Using them is usually unnecessary as you could've used an ID value
pointing to another table of values. That table can then be added to
with no risk to your existing queri
What exactly is wrong about using ENUM's?
Luc
sql,mysql
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again --
Well, the general consensus seems to be to stay violently away from SETs
and ENUMs :-) I'll certainly give that a shot. I still have to figure
out how to make sure that our credit card types and skill levels don't
get corrupted (MC, Mast
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
>
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: R
David T-G wrote:
I'm still trying to get a good handle on how sets can be useful to me.
You're thinking of ENUMs. SETs are for when you want multiple things
selected out of a list. So perhaps, favorite colours:
You have a column Colours
SET('black','purple','blue','green','yellow','orange
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
13 matches
Mail list logo
