Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Relationals vs. Objects Databases I
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