Re: Relationals vs. Objects Databases I

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.

Besides this theoretical shortcoming, SQL is impractical to use because of its lack of data structuring and behaviour encapsulation.

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

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

>Would object-orientated databases eliminate the need to write any
>programs?

So, OO databases do not eliminate problem domain programming, but they greatly reduce 'database' programming.

Richard Received on Tue Jan 27 1998 - 00:00:00 CST