Re: Decline of Science: Computer Science and Databases

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.

I think you didn't look exactly.

SQL doesn't support the features I posted.

(1) How would you query for *all* rows in *all* tables that contain the column "name" ?

(2) SQL doesn't know what interfaces are.

(3) It is not possible to execute server-side Java code from within a query statement on most SQL databases that I know.

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

(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!

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

(7) An SQL system always requires you to "navigate" from parent to child by IDs. S.O.D.A. understands class structures and it understands Collections, so you only need to use the member name.

I apologize for the examples being too simple to point out the benefits. I have been away from end-user-applications for a couple of years now and I am pretty bad at writing samples but I do remember the principle of the requirements that we had very well.

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

This is not possible with SQL. As soon as things get complicated, SQL starts to be a pain. Here is an example from my past:

http://groups.google.com/groups?as_umsgid=%3C9cefr7%24acp%2407%241_at_news.t-online.com%3E (see the end of the posting)

The statement was generated with a query generator because SQL statements of this order of complexity could not be built by hand.

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

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

Chuckle.

Prove it!

> > (5) SQL queries do not have a viewpoint, as in the last example.
>
> Can you expand this?

S.O.D.A. queries are hierarchical.
Every candidate of a query is "generated" by a root and navigates to members, if they exist.

SQL queries work with set logic. Turn an SQL query upside-down and you will get the same result.

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

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"?

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

I am in comp.databases.*theory* here, I forgot.

Kind regards,
Carl

--
Carl Rosenberger
db4o - database for objects - http://www.db4o.com