Re: Decline of Science: Computer Science and Databases
Date: Mon, 11 Nov 2002 16:37:18 +0100
Message-ID: <aqoirf$bt3th$1_at_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 01Received on Mon Nov 11 2002 - 16:37:18 CET