Re: ENUM type

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Jeff Davis <jdavis-pgsql(at)empires(dot)org>
Cc: Chris Travers <chris(at)travelamericas(dot)com>, PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: ENUM type
Date: 2005-07-26 22:28:49
Message-ID: 20050726222849.GE26758@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

On Tue, Jul 26, 2005 at 02:05:17PM -0700, Jeff Davis wrote:
> Jim C. Nasby wrote:
>
> >
> > 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
> > - no need to define RI
> > - no need to manually map between ID and real values (though of course
> > we should make it easy to get the ID too)
> >
> >
>
> Yeah, you're right. But this is only in the case where someone cares
> about using an int rather than a string type for some performance
> reason. If they don't mind wasting a few bytes (and it's really only a
> few bytes per record), then why not just use a check constraint when
> defining the table (like Chris explains)?

Normalization is about a lot more than just saving space in your base
tables. But since that's the example you used, you a) can't assume it's
only a few bytes and b) can't assume that those few bytes won't start to
seriously add up over the span of a few hundred million rows.

Remember: while disk space might be cheap, disk I/O bandwidth costs a
fortune.

> > Hopefully someone on -hackers can shed light on what's required to clean
> > up the parsing. One thing worth noting though, is that table definition
> > is a relatively small part of doing a migration. Generally, it's
> > application code that causes the most issues. Because of this, I think
> > there would still be a lot of benefit to an enum type that didn't
> > strictly follow the mysql naming/definition convention. In this case, it
> > might be much easier to have an enum that doesn't allow you to define
> > what can go into it at creation time; ie:
> >
> > CREATE TABLE ...
> > blah ENUM NOT NULL ...
> > ...
> >
> > ALTER TABLE SET ENUM blah ALLOWED VALUES(1, 2, 4);
>
> Interesting. I'm not really sure exactly what syntax we want to use, but
> as long as it gets the job done and is reasonable to implement.

Yeah, like I said the real key is just making sure it works the same
from an application's viewpoint (which generally doesn't involve any
DDL).
--
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 Josh Berkus 2005-07-26 22:30:11 Re: ENUM type
Previous Message Jim C. Nasby 2005-07-26 22:26:10 Re: ENUM type

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2005-07-26 22:30:11 Re: ENUM type
Previous Message Jim C. Nasby 2005-07-26 22:20:55 Re: ENUM type