Re: Data type to use for primary key

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Cc: Rod Taylor <pg(at)rbt(dot)ca>, Alexandre Leclerc <alexandre(dot)leclerc(at)gmail(dot)com>
Subject: Re: Data type to use for primary key
Date: 2004-11-23 06:00:41
Message-ID: 200411222200.41729.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Rod,

> It would be nice if PostgreSQL had some form of transparent surrogate
> keying in the background which would automatically run around and
> replace your real data with SERIAL integers. It could use a lookup table
> for conversions between the surrogate and real values so the user never
> knows that it's done, a bit like ENUM. Then we could all use the real
> values with no performance issues for 1) because it's an integer in the
> background, and 2) because a cascade only touches a single tuple in the
> lookup table.

Sybase does this, and it's a feature I would dearly love to emulate. You can
just refer to another table, without specifying the column, as an FK and it
will create an invisible hashed key. This is the type of functionality Codd
was advocating -- invisible, implementation-automated surrogate keys -- in
the mid 90's (don't have a paper citation at the moment).

So you'd just do:

create table client_contacts (
fname text not null,
lname text not null,
client foriegn key clients,
position text,
notes text
);

and the "client" column would create an invisible hashed key that would drag
in the relevant row from the clients table; thus a:

select * from client_contacts

would actually show the whole record from clients as well.

--
Josh Berkus
Aglio Database Solutions
San Francisco

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Pierre-Frédéric Caillaud 2004-11-23 08:39:52 Re: Data type to use for primary key
Previous Message Bruce Momjian 2004-11-23 02:26:05 Re: scalability issues on win32