Hi,
for my 2c worth, performance is the least important of the things you need
to consider regarding use of surrogate keys.
I use surrogate keys for all situations except the simplest code/description
tables, and this is only when the code has no meaning to the application. If
there is any possibility that you will want to update or re-use codes
(attaching a different meaning to them) then surrogate keys are the way to
go..
Thus I see it more as an issue of business logic than performance. There are
of course many other considerations with relational theory and stuff like
that which you could debate endlessly. I expect that googling on "surrogate
keys" would yeild interesting results.
Regards
Iain
----- Original Message -----
From: "Markus Bertheau" <twanger@bluetwanger.de>
To: <pgsql-sql@postgresql.org>
Sent: Tuesday, July 20, 2004 9:16 PM
Subject: [SQL] surrogate key or not?
> Hi,
>
> I have a database that has types in them with unique names. These types
> are referenced from other tables through a surrogate integer key. I'm
> now wondering if I should eliminate that surrogate key and just use the
> name as the primary key. Afaiu, surrogate keys are primarily there to
> make joining tables or otherwise searching for a record faster, because
> it's faster to compare two integers than it is to compare two strings.
>
> Now when I want to search for a type in types or another table that
> references types(type_id), under what circumstances is it advisable to
> have a surrogate integer key and not use the unique type name? Is
> searching for an integer as fast as is searching for a string when both
> have an index? How many records in the type table do I need to make a
> surrogate key a not unsignificantly faster way to retrieve a row? What
> about joins? Are these the right questions?
>
> Thanks.
>
> --
> Markus Bertheau <twanger@bluetwanger.de>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
