Re: Surrogate Key vs Production Key

wizofoz2k_at_yahoo.com.au (Noons) wrote in message news:<73e20c6c.0410202043.3268333_at_posting.google.com>...

>
> Suffice to say that non-relational databases do NOT allow
> for ad-hoc relationships between any two entities (tables).

Just a quibble: I know of at least one product that is still supported that can layer R on top of (what was once DEC) RMS files - it follows description files and a small set of rules to figure out primary keys and such. Also works with Rdb, Oracle and MS. The physical expression of the metadata, the logical expression of the relations and the physical underlying database are not mutually exclusive.

People who code with this for commercial products can't know exactly how it will be implemented, so you don't generally see surrogate keys.  But there are some for internal metadata (or is it meta-metadata?) use. It's a bitch-and-a-half to fix should anything go wrong with those internals. And, er, naturally, things will go wrong when people try to do DDL directly with SQL (or whatever) behind the products back. And ocassionally when the product twists itself into knots. And there's some implicit and explicit domain definition that can just confuse the heck out of people.

The transactional code that people write with such a product, well, that's another story. :-O

jg

--
@home.com is bogus.
Never trust any programming language over 30: 
http://www.jacobsschool.ucsd.edu/Pascal/