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.
Advertising
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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
