Re: Fw: Is SQL silly as an RDBMS<->app interface? - Mailing list pgsql-general
From | elein |
---|---|
Subject | Re: Fw: Is SQL silly as an RDBMS<->app interface? |
Date | |
Msg-id | 20030713112636.A12760@cookie Whole thread Raw |
In response to | Fw: Is SQL silly as an RDBMS<->app interface? ("Vincent Hikida" <vhikida@inreach.com>) |
List | pgsql-general |
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 >
pgsql-general by date: