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
