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

Quel rules.

elein(at)varlena(dot)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(dot)Christofides(at)itia(dot)ntua(dot)gr>
> > To: <pgsql-general(at)postgresql(dot)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
>