Обсуждение: Fw: Is SQL silly as an RDBMS<->app interface?
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 > > >
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 >
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 #
Jan Wieck wrote:
> elein wrote:
> > Quel rules.
>
> PostQUEL ... we should have kept a compatibility mode for that.
I prefer SQL for a few reasons:
nested queries
aggregates that make sense
Does anyone remember how QUEL had you put the qualifiction inside the
aggregate parens. And the correlated aggregates were weird, sum(col1 by
col2 where col3 = ...). It was a little subquery with a correlated
aggregate. It still makes my head spin.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
(Postquel, quel, whatever. My ingres days are showing.) Actually the aggregates made much more sense in [Post]quel than SQL. The individual aggregate is qualified separately so that it does not mess with the entire query. (Group by grief anyone?) Therefore it was able to select several different aggregates in one query. (But don't ask me to remember the syntax...) elein On Mon, Jul 21, 2003 at 03:57:33PM -0400, Bruce Momjian wrote: > Jan Wieck wrote: > > elein wrote: > > > Quel rules. > > > > PostQUEL ... we should have kept a compatibility mode for that. > > I prefer SQL for a few reasons: > > nested queries > aggregates that make sense > > Does anyone remember how QUEL had you put the qualifiction inside the > aggregate parens. And the correlated aggregates were weird, sum(col1 by > col2 where col3 = ...). It was a little subquery with a correlated > aggregate. It still makes my head spin. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 >
Yes, it was more powerful because you could do aggregates in the query independent of the results returned by the query. The 'by' feature of aggregates always confused me because it would modify the aggregate WHERE clause (that was independent of the outer query) and restrict the aggregate to only process rows where the outer query's column value matched the same column's value in the aggregate. --------------------------------------------------------------------------- elein wrote: > (Postquel, quel, whatever. My ingres days are showing.) > > Actually the aggregates made much more sense in [Post]quel > than SQL. The individual aggregate is qualified separately so that > it does not mess with the entire query. (Group by grief anyone?) > Therefore it was able to select several different aggregates in one > query. (But don't ask me to remember the syntax...) > > elein > > > On Mon, Jul 21, 2003 at 03:57:33PM -0400, Bruce Momjian wrote: > > Jan Wieck wrote: > > > elein wrote: > > > > Quel rules. > > > > > > PostQUEL ... we should have kept a compatibility mode for that. > > > > I prefer SQL for a few reasons: > > > > nested queries > > aggregates that make sense > > > > Does anyone remember how QUEL had you put the qualifiction inside the > > aggregate parens. And the correlated aggregates were weird, sum(col1 by > > col2 where col3 = ...). It was a little subquery with a correlated > > aggregate. It still makes my head spin. > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 359-1001 > > + If your life is a hard drive, | 13 Roberts Road > > + Christ can be your backup. | Newtown Square, Pennsylvania 19073 > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
----- Original Message ----- From: "Bruce Momjian" <pgman@candle.pha.pa.us> To: "elein" <elein@varlena.com> Cc: "Jan Wieck" <JanWieck@Yahoo.com>; "Vincent Hikida" <vhikida@inreach.com>; <pgsql-general@postgresql.org> Sent: Thursday, July 24, 2003 5:35 PM Subject: Re: Fw: [GENERAL] Is SQL silly as an RDBMS<->app interface? > > Yes, it was more powerful because you could do aggregates in the query > independent of the results returned by the query. > > The 'by' feature of aggregates always confused me because it would > modify the aggregate WHERE clause (that was independent of the outer > query) and restrict the aggregate to only process rows where the outer > query's column value matched the same column's value in the aggregate. > Actually, I used a hierarchical/relational DBMS called Nomad in 1981. If I understand Bruce, Nomad could do the same thing. I could aggregate at different levels in the same query. Each aggregate created a break and I could add whatever code I wanted at the level. I could also refer to any level of aggregate in the rest of the query. I could also refer to any level aggregate in the rest of the code. This meant that I could for example calculate what percentage of the total the individual row was. The only problem was that I could only join two tables at a time so if I wanted to join several tables I had to have several statements. Each statement created an intermediate table which was easy to refer to in subsequent statements. Vincent
You could do something like:
retrieve (a.dept, x=sum(a.total by a.dept) / sum(a.total));
if I remember correctly.
---------------------------------------------------------------------------
Vincent Hikida wrote:
>
> ----- Original Message -----
> From: "Bruce Momjian" <pgman@candle.pha.pa.us>
> To: "elein" <elein@varlena.com>
> Cc: "Jan Wieck" <JanWieck@Yahoo.com>; "Vincent Hikida"
> <vhikida@inreach.com>; <pgsql-general@postgresql.org>
> Sent: Thursday, July 24, 2003 5:35 PM
> Subject: Re: Fw: [GENERAL] Is SQL silly as an RDBMS<->app interface?
>
>
> >
> > Yes, it was more powerful because you could do aggregates in the query
> > independent of the results returned by the query.
> >
> > The 'by' feature of aggregates always confused me because it would
> > modify the aggregate WHERE clause (that was independent of the outer
> > query) and restrict the aggregate to only process rows where the outer
> > query's column value matched the same column's value in the aggregate.
> >
>
> Actually, I used a hierarchical/relational DBMS called Nomad in 1981. If I
> understand Bruce, Nomad could do the same thing. I could aggregate at
> different levels in the same query. Each aggregate created a break and I
> could add whatever code I wanted at the level. I could also refer to any
> level of aggregate in the rest of the query. I could also refer to any level
> aggregate in the rest of the code. This meant that I could for example
> calculate what percentage of the total the individual row was. The only
> problem was that I could only join two tables at a time so if I wanted to
> join several tables I had to have several statements. Each statement created
> an intermediate table which was easy to refer to in subsequent statements.
>
> Vincent
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Boy! That sounds versitile!