Re: Unknown SQL

From: Bob Badour <bbadour_at_golden.net>
Date: Sat, 12 May 2001 06:51:11 -0400
Message-ID: <kH8L6.92$5L6.26362929_at_radon.golden.net>


>At the risk of stirring up the dogs and cats, I would question the validity
>of this statement. One of the criticisms leveled against the object
>databases is that they are too tightly coupled to the application. However,
>the above data model is fraught with application implementation details.

...
>How is the RDBMS superior there?

Jim,

I do not think it is entirely fair to point at a very poor design using an SQL-like language, and blame the problems on a relational database management system.

>So, a row in the Customers table is analogous to a Customer object. An
>accessor method, get_balance() could return the precomputed, cached (if
>potentially out of date) balance attribute stored with the Customer object
>(just as the relational model above) or it could compute it on the fly by
>accessing the transactions (both credits AND debits) associated with this
>customer.

As I am sure you know, the relational model does not stipulate anything at the physical level except that the DBMS should allow significant independence between the physical and logical views of the data. A relational system could easily cache pre-calculated aggregates or even provide indexes that store partial aggregates to improve the performance of such sums. The big differences is the user specifies the exact aggregate required and does not need to know about any special functions like get_balance().

> The difference is that the OODBMS will not have to do the join
>(WHERE c.custid = p.custid) because the transactions associated with a
>customer are already associated with the customer, allowing direct access.

Huh? Of course it has to do the join. A relational database management system need not perform any more poorly than a network model OODBMS. While I would not claim that current vendors provide much physical independence, some vendors currently provide data clustering where the rows of one table are stored with the corresponding rows of another. Received on Sat May 12 2001 - 12:51:11 CEST

Original text of this message