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

Quel rules.

elein@varlena.com

(For those of you who do not know, quel was the original
query language used by postgres.  And ingres.)

On Sun, Jul 13, 2003 at 10:12:16AM -0700, Vincent Hikida wrote:
> 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
> > >
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>