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: Relationals vs. Objects Databases I

Re: Relationals vs. Objects Databases I

From: Jeremy Rickard <Jeremy_at_SPAM.demon.co.uk>
Date: 1998/01/27
Message-ID: <Lx1ObBAYckz0EwzG@jbdr.demon.co.uk>#1/1

In article <6albgf$gio_at_news3.euro.net>, Richard Ronteltap <rontltap_at_euronet.nl> writes
>Jeremy Rickard wrote in message ...
>>"Just" joins? Elimination of the need to program joins (and re-program
>>when the access paths become inefficient) is a major benefit in itself.
>>The programs are little more than simple shells to hold the SQL.
>
>
>Ok. Now say you use an OO language with an ODBMS. You derive you
>classes from a base class that manages 2-way retations between objects
>(e.g. ObjectStore) Now do you still need the separate language SQL?
>
>>>I think a database programming language should be capable to to
>>>all of the work.
>>In principle I do agree, and theoretically SQL is capable of this.
>
>No. SQL is *theoretically* incapable to do all the work because it
>is no computationally complete. (Has to do with Turing machines).
>
>For example: Tell me the SQL statement that gives the top 100
>most expensive products in a product table with name and price
>attributes.

SELECT
  A.price,
  A.product
FROM
  product AS A
WHERE
  (
    SELECT
      COUNT(*)
    FROM
      product AS B
    WHERE
      B.price < A.price
  ) < 100
ORDER BY
  A.price DESC

... would be along the right lines. I can think of more efficient variations. I'd recommend a cursor though! Another example? Exploding variable-depth hierarchies would have been be a good "attack", although DB2 supports recursive SQL via common table expressions. Oracle also supports recursive queries with a different syntax.

>Besides this theoretical shortcoming

Not proved!

>SQL is impractical to use because of its lack of data structuring and
behaviour encapsulation.
The structure exists between tables rather than in one stream of "objects", granted.

>>Even with a pure set-based approach you still usually want a program to
>>host the SQL, report success or failure, and do this and that. Sure,
>>you can invent a proprietary (or even standard) extension to SQL that
>>does this, but what would this do that a plethora of other languages
>>don't do already?
>>The point about these programs that host SQL is that they should be, and
>>generally are, trivial. So I'm afraid I don't really see the problem.
>
>
>My 'problem' with your (traditional) approach is that, you have to use at
>least
>2 programming languages (e.g.: COBOL and SQL) that do not integrate
>well (aka impedance mismatch).

There may be applications where this is true. I have personally come across them in commercial applications to date.

>An ODBMS integrates seamlessly with the OO programming language
>used. The 'database' part is nearly invisible. You only have to learn 1
>OO language and get structuring of data and behaviour encapsulation
>for 'free'.

I'll take your word for it. From my brief experience with MFC, I'd say a problem with OO programming is that you have to familiarise yourself with the behaviour of hundreds of objects, rather than few basic principles.

-- 
Jeremy Rickard

(To email, change "SPAM" to "jbdr" in address.)
Received on Tue Jan 27 1998 - 00:00:00 CST

Original text of this message

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