Re: Decline of Science: Computer Science and Databases
Date: Mon, 04 Nov 2002 15:06:57 +0100
Message-ID: <aq5uu1$6svfj$1_at_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 - 15:06:57 CET