Re: Surrogate Key vs Production Key

joel-garry_at_home.com (Joel Garry) wrote in message news:<91884734.0410211331.7eccd81e_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.

Look, I used a query product in the very early 80s (on mainframes) that used to let me create relational joins on top of Codasyl databases. Or flat files, for that matter. Long before Oracle was a twinkle in anyone's eye. Or any other R-database other than probably SQL-DS. Query products have been able to do that for a long time using meta-schemas. That doesn't make these products into a RDBMS.

> use. It's a bitch-and-a-half to fix should anything go wrong with
> those internals.

Of course. If ANY internals go wrong in ANY product, it will be a bitch and a half to fix. No matter what design technique you use.

> And, er, naturally, things will go wrong when people
> try to do DDL directly with SQL (or whatever) behind the products
> back.

Sure. One of Codd's 12 rules for considering a database product as relational was precisely that this could not be done with such a product. Ie, that no one should be able to subvert the database engine by using a language other than the database's native one to access the data. Something none of these query products were ever able to do. Precisely because they were bolt-on products, not native.

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

Aye!..... Received on Thu Oct 21 2004 - 22:18:28 CDT