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