Re: Surrogate Key vs Production Key

joel-garry_at_home.com (Joel Garry) wrote in message news:<91884734.0410221642.7635fec1_at_posting.google.com>...

> Now, now, we know twinkles before 1980.

Sure. And it was NOT Oracle!
MOF, Univac's Mapper was around since 1976... :)

> You know, I'm pretty sure you are right, but look at numbers 4 and 5
> here:
>
> http://encyclopedia.thefreedictionary.com/Codd's%2012%20rules

That list is far from correct. Date used to have the original one in one of his first books. Then he added a few of his own. Which apparently made it to this list as well. But using it, anyway:

4 is mostly it, really. Means we should not have two access methods and languages, one for processing data and another to read/manage the metadata. Which Oracle has always met, BTW: the entire dictionary is nothing more nothing less than a bunch of (guess what?) *tables*, as you well know. And of course 12 is always relevant.

> I can get to the catalog (in the Oracle version) with SQL, the problem
> is not necessarily knowing what to do when I get there!

Sure. You shouldn't be doing much either: the idea is to be able to query it using the same language. Not change it. But indeed you can, although it will cause the eternal ire of Oracle support! However, that is what recursive SQL is all about, isn't it?

> And of course, RDBMS or not, it still allows an ad-hoc relationship
> between any two entities (tables).

Try:

select ........
from a,b
where a.col between b.col1 and b.col2;

Very few non-relational will allow this kind of join relationship, ad-hoc or not. You can try as well with more complex joins involving ranges and expressions instead of columns. Received on Sat Oct 23 2004 - 10:02:27 CDT