Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Surrogate Key vs Production Key

Re: Surrogate Key vs Production Key

From: Joel Garry <joel-garry_at_home.com>
Date: 22 Oct 2004 17:42:11 -0700
Message-ID: <91884734.0410221642.7635fec1@posting.google.com>


wizofoz2k_at_yahoo.com.au (Noons) wrote in message news:<73e20c6c.0410211918.2061e3e1_at_posting.google.com>...
> 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.

Now, now, we know twinkles before 1980.

>
>
>
> > 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.

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 (just happened to be the first thing found googling). I don't see anything ruling out subversion, although I'll grant a summary of the rules won't encompass everything Codd said :-) Better summary gladly accepted.

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! And in fact, the non-SQL language in question can, er, should, do it too, and it is documented as to what you can do. So it seems that this product kinda does what you say, certainly in the RMS layered version. In the meantime, I have a dictionary to fix, with SQL, because it is too corrupt for the non-SQL. VMS style error messages on a unix box are always so amusing.

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

jg

--
@home.com is bogus.                                                 
<> <>
%DCL-W-SOFTONEDGEDONTPUSH, Software On Edge - Don't Push.            \
V /
panic: ifree: freeing free inodes...                                  
o
Received on Fri Oct 22 2004 - 19:42:11 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US