From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
Cc: | "PostgreSQL advocacy" <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: ENUM type |
Date: | 2005-07-26 21:30:49 |
Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3415C2EB2@Herge.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-general |
Jim C Nasby:
> OK, but compare the amount of work you just described to the
simplicity
> of using an enum. Enum is much easier and simpler for a developer. Of
> course in most cases the MySQL way of doing it is (as has been
> mentioned) stupid, but done in the normal, normalized way it would
> remove a fair amount of additional work on the part of a developer:
>
> - no need to manually define seperate table
create table color (color text);
insert into color values ('red'); -- etc
> - no need to define RI
references color
> - no need to manually map between ID and real values (though of course
if you use color as p-key this is unnecessary
> we should make it easy to get the ID too)
again, in this case the color should be the id and using a surrogate key
is poor design. If that's too much typing you have the option of a
check constraint which is superior to enum in just about every way,
particularly if encapsulated into a domain (although inferior to RI
solution, IMO).
Merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Jochem van Dieten | 2005-07-26 22:11:47 | Re: ENUM type |
Previous Message | Josh Berkus | 2005-07-26 21:27:33 | Re: SQL/PSM for 8.2 will offer ANSI/ISO, MySQL, and DB2 Compatibility |
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2005-07-26 21:44:02 | Re: back-end triggers front-end to update |
Previous Message | Adam O'Toole | 2005-07-26 21:25:23 | back-end triggers front-end to update |