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

elein wrote:
> Quel rules.

PostQUEL ... we should have kept a compatibility mode for that.


Jan

>
> 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
>>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster



--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #