From: | "David Clarke" <pigwin32(at)gmail(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Table design question |
Date: | 2006-06-02 01:19:25 |
Message-ID: | 12b7ac1e0606011819k483760fbq910f4fcf9dcf7762@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On 6/2/06, postgres(at)jal(dot)org <postgres(at)jal(dot)org> wrote:
> On Thu, 01 Jun 2006, Chris Browne wrote:
>
> > Celko is decidedly *NOT* promoting the notion that you should use a
> > 100 byte long "natural key."
> >
> > Jamie's comments of "Orthodox versus Reform" seem reasonably
> > appropriate in outlining something of the difference between the
> > positions.
>
> Just to be clear, that was all I was trying to do. I probably should
> have mentioned that any attempt to use such an attribute as a PK should
> be met with a baseball bat or other shillelagh-ish implement, but was
> interrupted several times during that email drafting.
>
> > I may not care for doing this; you may not either; a company that
> > builds auto parts that they want to sell into the automotive industry
> > may care about standardizing their part IDs quite a lot.
>
> This is another important point. In some situations, a rigid data model
> can be a godsend to coders. If you happen to sit in such an enviable
> position, I would encourage you to take advantage of it. (This doesn't
> mean picking bad keys, of course.)
>
> None of this should be taken as bashing Celko - he's a smart man and an
> excellent source of advice.
>
> -j
>
Thanks everyone who replied (and also for the insightful and measured
responses, not every news group is so lucky). I had progressed down
the path of the serial id column but re-reading Celko's book - he
spends some pages railing against "proprietary auto-numbering
features" - I wanted to feel confident I was making the right choice.
Thanks again
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Bono | 2006-06-02 01:44:18 | Re: Am I crazy or is this SQL not possible |
Previous Message | operationsengineer1 | 2006-06-02 00:30:25 | Re: Advanced Query |