Re: S.O.D.A. database Query API - call for comments

From: Carl Rosenberger <carl_at_db4o.com>
Date: Sat, 28 Apr 2001 15:18:37 +0200
Message-ID: <9cefv8$rb6$00$1_at_news.t-online.com>


Lee Fesperman wrote:
> Hmm, there some real advantages to queries in string form:

Hi Lee,

I am not sure if we are talking about the same SQL language. Your points 1, 3, and 4 might be arguments for "SELECT person_name FROM person". The API is inteded for some more complex problems.

Some comments:

> + easy to build using standard facilities

No.
- SQL does not have a "viewport" on data. This is a non-human approach to view sets and a cause for a very long learning curve. - SQL causes terrible pains if you add more and more constraints incrementally. You need to reunderstand the entire statement. SQL statements can not be split into individual parts with meanings. - Every join needs to declare table and field explicitely. - Have you ever written an outer join over 2 or more tables containing where clauses?
- Worst of all:
SQL does not match the object-oriented paradigm of modern programming languages.
Please feel free to write an SQL statement for the following example, by using standard facilities if you wish:

class Person
  CommunicationMedium[] comMedia;
class CommunicationMedium
class Phone extends CommunicationMedium
class MobilePhone extends Phone

"I would like to know all Persons, that don't have a mobile phone."

> + usually the most compact form for network transport

No.
What's efficient about a string format, that even sends keywords as uncompressed strings?
Is a plain XML file more efficient than a zipped file?

> + portable to multiple DBMSs

No, except for extremely simple cases.
Considering you would want to build an application that runs under Oracle, Sybase and MSSQL:
Which outer join syntax would be used?
How would you generate unique IDs?
How would you fetch these IDs to insert them into foreign keys? Which isolation levels would match?
How would you rename tables or columns?

   ...O.K., nice idea...
   What would happen to your integrity constraints on the way?

Sorry, SQL is nowhere near to being an exchangable standard.

> + human readable.

No, because you can not split statements to isolate problems.

I have posted this mail with a typical SQL statement from my past employment to comp.databases.object.
The statement makes the mail too large for crossposting. Can you read it?
What would be your approach to make it readable?

Kind regards,
Carl Received on Sat Apr 28 2001 - 15:18:37 CEST

Original text of this message