Re: Decline of Science: Computer Science and Databases

From: Leandro Guimarães Faria Corsetti Dutra <lgcdutra_at_terra.com.br>
Date: Mon, 04 Nov 2002 15:06:57 +0100
Message-ID: <aq5uu1$6svfj$1@ID-148886.news.dfncis.de>

Carl Rosenberger wrote:

> Leandro Guimarães Faria Corsetti Dutra wrote:
>

>>> Are the examples really that hard to read?
>> 
>> Yes.

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

> S.O.D.A. does have trade-offs at legibility due to the nature of the
> used OO language (Java) and due to the fact that we wanted to make it
> possible to plug existing objects into a query.
>
> Step 1: Constrain the query by any object. Constraint constraint =
> Query#constrain(anyComplexObjectHere);
>
> Step 2: Choose the comparator. constraint.greater();

        This still doesn't explain the huge difference in both size and legibility. 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.

>> Just see that for all but two of the examples, your comments are 
>> actually much simpler, more logical SQL statements.

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

> (5) SQL queries do not have a viewpoint, as in the last example.

        Can you expand this?

>> And that given that SQL is already below relational standards.

>
> S.O.D.A. is not meant as an end-user language to type it into a
> console. It will serve as an API below an SQL query parser that we
> will build on top.
>
> ....and S.O.D.A. can already do quite a few things that SQL can't.
>
> S.O.D.A. is meant to reduce the coding work of an application
> programmer, so he does not need to convert the existing objects in
> his application to a string query language.

        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.

>> The other two are simple enough to be expressed in a relational 
>> system also much clearer.

>
> "Clearer" is a question of the standpoint.
>
> S.O.D.A. is direct construction of the query tree. This
> representation is "clearer" for a computer. S.O.D.A. is written to
> make an SQL query parser obsolete. Therefore a S.O.D.A. database
> engine will need a smaller footprint and it will run with less
> ressource consumption on embedded systems, mobile phones or Java
> cards.
>
> S.O.D.A. also works better for setting up very complex query
> expressions: You can add one constraint at a time and you can
> delegate the work of doing this to individual methods. There is not a
> long SQL statement that you need to monitor and debug.

        Don't mix SQL and relational, please. Received on Mon Nov 04 2002 - 08:06:57 CST