Re: ENUM type

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: ENUM type
Date: 2005-07-26 22:26:10
Message-ID: 20050726222610.GD26758@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-general

On Tue, Jul 26, 2005 at 05:30:49PM -0400, Merlin Moncure wrote:
> 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).

Please go back through the original thread. The original comment was
regarding adding an enum type that actually made sense; ie: it stored an
int in the base table that referenced a parent table. The original
poster was arguing that enum didn't really buy anything over doing that
the manual method (create seperate table; fill that table with values;
create base table with RI, and finally, make sure that everything that
touches the base table can do mapping, or add a bunch of other stuff to
do the mapping automatically). My argument is that simply specifying

fieldname ENUM(...)

is a heck of a lot easier on developers than doing all those manual
steps, yet it still does things in the correct, normalized manner
(unlike MySQL).
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Jim C. Nasby 2005-07-26 22:28:49 Re: ENUM type
Previous Message Jim C. Nasby 2005-07-26 22:20:55 Re: ENUM type

Browse pgsql-general by date

  From Date Subject
Next Message Stephan Szabo 2005-07-26 22:39:56 Re: Problem with text_pattern_ops
Previous Message Martijn van Oosterhout 2005-07-26 22:09:50 Re: transaction timeout