Fw: Is SQL silly as an RDBMS<->app interface?

Oops forgot to CC the list.

> Antonios,
>
> I have no problems myself with SQL but I know of two groups that are
> critical of SQL.
>
> There are some OO types who may be critical. A somewhat SQL friendly
> perspective from an OO guru is
> http://www.martinfowler.com/articles/dblogic.html.
>
> Another group that is critical of SQL is followers of C.J. Date. I used to
> read all of Date's writings but have been somewhat remiss lately. Date is
> basically a relational theorist who believes that SQL was a hack and
should
> not have been made a standard. He has recently championed a relational
> language called "D". I believe that there is an implementaion of D called
> "Dataphor" that he mentions on his site. Date's web pages are at
> www.dbdebunk.com. Since I haven't read his stuff in several years I don't
> know much about "D" and Dataphor.
>
> Vincent Hikida,
> Member of Technical Staff - Urbana Software, Inc.
> "A Personalized Learning Experience"
>
> www.UrbanaSoft.com
>
> ----- Original Message -----
> From: "Antonios Christofides" <A.Christofides@itia.ntua.gr>
> To: <pgsql-general@postgresql.org>
> Sent: Sunday, July 13, 2003 3:24 AM
> Subject: [GENERAL] Is SQL silly as an RDBMS<->app interface?
>
>
> > Hi, this is a general RDBMS question, not specific to pg. It occurred to
> > me while I was trying to design an interface between application and
> > SQL.
> >
> > Suppose that the user fills in a complex query form, and you are coding
> > the application that converts the user's input to a where clause. It may
> > prove beneficial if you construct a treelike structure like this:
> >
> >         AND
> >          |
> >          +-OR
> >          |  |
> >          |  + Condition A
> >          |  |
> >          |  + Condition B
> >          |
> >          +-OR
> >             |
> >             + Condition C
> >             |
> >             + AND
> >                |
> >                + Condition D
> >                |
> >                + Condition E
> >                |
> >                + Condition F
> >
> > This would become
> >
> >    WHERE (A OR B) AND (C OR (D AND E AND F))
> >
> > It seems complex at first, but the code will be cleaner, scale better,
> > and be made portable easier if you are adding nodes and leaves to a tree
> > as you are scanning the user's input, than if you try to construct a
> > where clause directly.  After finishing with the tree, it is
> > straightforward to convert it to a where clause, after which you send
> > the SQL to the RDBMS.
> >
> > What will the RDBMS do next? It will parse your SQL statement and
> > presumably convert it to a tree of conditions. Well, I had that ready in
> > the first place!
> >
> > Whether my idea about the tree is good or not, it is true that the
> > application initially has its data in some data structures suitable for
> > computers rather than humans; it converts them to SQL, which is suitable
> > for humans, only so that the SQL will be converted back to structures
> > suitable for computers. The most obvious example is that integers are
> > converted to decimal by the application only to be converted back to
> > binary by the RDBMS.
> >
> > I understand that SQL is the interface between apps and RDBMS's because
> > of history, not because it is correct design.  Could you point me to a
> > link or book or paper that deals with this paradox? Thanks!
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 8: explain analyze is your friend
> >
>