From: | "David Clarke" <pigwin32(at)gmail(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Table design question |
Date: | 2006-06-01 11:05:54 |
Message-ID: | 12b7ac1e0606010405u6e062f71mf4adbaeb6c46df5f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
I'm reading Joe Celko's book SQL Programming Style for the second time
and although I've been an OO developer for quite a few years I'm
fairly green wrt SQL. Joe is obviously something of a curmudgeon and I
would fall squarely into his newbie OO developer ordinal scale and I'm
trying to avoid the slide into stupid newbie OO developer.
So I'm designing a table and I'm looking for an appropriate key. The
natural key is a string from a few characters up to a maximum of
perhaps 100. Joe gets quite fierce about avoiding the use of a serial
id column as a key. The string is unique in the table and fits the
criteria for a key. So should I follow Joe's advice and use my natural
key as the primary key? It sounds reasonable but it will mean at least
one other table will have the string as a foreign key. My postgres
intro book has id columns all over the place but is it really that big
an issue these days to have a 100 character primary key? Are there
postgres-specific implications for either approach?
Thanks
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Miroslav Šulc | 2006-06-01 13:26:09 | SELECT DISTINCT too slow |
Previous Message | Tom Lane | 2006-05-31 21:50:19 | Re: DELETE ... USING ... - 8.0 and 8.1 compatibility problem |