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
Show quoted text
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 FThis 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.)
Show quoted text
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 andshould
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 FThis 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?
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 andshould
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 FThis 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?---------------------------(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
Show quoted text
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 senseDoes 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 senseDoes 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