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

Home -> Community -> Usenet -> comp.databases.theory -> Re: Decline of Science: Computer Science and Databases

Re: Decline of Science: Computer Science and Databases

From: Leandro Guimar„es Faria Corsetti Dutra <lgcdutra_at_terra.com.br>
Date: Mon, 11 Nov 2002 16:37:18 +0100
Message-ID: <aqoirf$bt3th$1@ID-148886.news.dfncis.de>


Carl Rosenberger wrote:

> Leandro Guimar„es Faria Corsetti Dutra wrote:
>

>>> Obviously, since you know SQL and S.O.D.A. is new.
>> 
>> No.  Since SQL is simple, logical and relatively concise.  Compare
>> that to your long-winded, complex statements.

>
> SQL doesn't support the features I posted.
>
> (1) How would you query for *all* rows in *all* tables that contain
> the column "name" ?

        This isn't a SQL problem, but just a lack of integration of the catalog in the DBMS.

        Anyway I am not defending SQL. I am the first to point SQL braindamage. My point is that your syntax is hideous and unnecessarily complex.

        Exercise: translate your examples into Tutorial D.

        That said, most of the other points bashing SQL become irrelevant. But I will answer some of them anyway.

> (4) How would you query for a regular expression?

        PostgreSQL has a very interesting ~= operator that takes regexps. Not a big deal, it is just an operator to be defined on textual types.

> (5) ...or any other Java callback. Yes, some SQL databases do provide
> stored procedures but is there a common standard? Java will be the
> standard!

        So what? You don't need to corrupt the RM to use Java.

> (6) In the UNION example I posted, the WHERE clause is used for both
> "tables". Imagine a more complex query with a dozen classes and a
> dozen constraints. In an SQL UNION statement you would need 144 WHERE
> expressions, S.O.D.A. only needs 12.

        Hm. What prevents one from restricting (WHERE) on unions?

>> This still doesn't explain the huge difference in both size and 
>> legibility.

>
> As soon as examples get a little more complex, S.O.D.A. benefits from
> object-orientation and query set-up code will be much more legible
> than SQL: You can build up parts of the query in separate methods and
> you can reuse methods. Objects can be added to the query graph one at
> a time.

        Again, you are ignoring SQL isn't relational. No such problem with relational, only with SQL.

>> Also, an object AFAICU is but a value or variable, so should be
>> represented as a normal, but complex and perhaps user-defined, 
>> type.  No need to confound user with implementation details at the 
>> database level.

>
> That's very nice in theory, but someone has to do the job to build
> the implementation details.

        Alphora Dataphor. Download and give it a try.

>>> The examples listed are not possible with common SQL databases:
>> 
>> As I said, SQL is substandard.  All this is
>> implementation-dependent, and can be done quite easily inside the
>> relational model.

>
> Prove it!

        C'mon, you're in c.d.theory. If you think the relational model can't do something, *you* have to prove it. I won't loose my time to explain the obvious.

>> So clearly it's not general-purpose, and not up to relational 
>> standards.  So it's kind of off-topic in the context of this
>> thread.

>
> Sorry for popping up, but I felt invited by "Decline of Science".
> S.O.D.A. is completely new. Of course it doesn't supply the complete
> functionality of SQL immediately.
>
> Do you think it's a "decline"?

        Yes, because it will never supply the complete functionality and simplicity of the RM.

-- 
  _
/ \ Leandro Guimar„es Faria Corsetti Dutra        +41 (21) 216 15 93
\ / http://homepage.mac.com./leandrod/        fax +41 (21) 216 19 04
  X  http://tutoriald.sourceforge.net./      Orange Communications CH
/ \ Campanha fita ASCII, contra correio HTML      +41 (21) 644 23 01
Received on Mon Nov 11 2002 - 09:37:18 CST

Original text of this message

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