home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6110 < prev    next >
Encoding:
Text File  |  1992-08-13  |  3.3 KB  |  78 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!zrz.tu-berlin.de!math.fu-berlin.de!Sirius.dfn.de!chx400!bernina!neptune!nugget.inf.ethz.ch!marti
  3. From: marti@nugget.inf.ethz.ch (Robert Marti)
  4. Subject: Re: nested SQL select
  5. Message-ID: <1992Aug14.071343.1758@neptune.inf.ethz.ch>
  6. Sender: news@neptune.inf.ethz.ch (Mr News)
  7. Nntp-Posting-Host: nugget.inf.ethz.ch
  8. Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
  9. References:  <3761@keele.keele.ac.uk>, <l8h5i5INNhvg@jethro.Corp.Sun.COM>
  10. Date: Fri, 14 Aug 1992 07:13:43 GMT
  11. Lines: 65
  12.  
  13. In article <3761@keele.keele.ac.uk>, csa09@seq1.keele.ac.uk (Paul
  14. Singleton) writes:
  15. ps> How, in general, can I nest SQL 'select' expressions?
  16. ps> I have a table T(A,B,C) and I want effectively to
  17. ps>   select A, count(B) from ( project A, B from T ) group by A
  18. ps> [ ... ]
  19. ps> Is there a general algorithm for translating relational algebra
  20. ps> expressions into SQL?
  21.  
  22. I agree that "good" (orthogonal) language design should indeed
  23. allow something like
  24.   select <attribute-list>
  25.   from   ( select <attribute-list>
  26.            from   <table-name>
  27.            ... )
  28.   ...
  29. However, I would just like to point out that "count" and in
  30. particular "group by" are not considered as part of relational
  31. algebra:  Relational algebra operators are selection, projection,
  32. union, intersection, difference, cartesian product/join, and
  33. division (but see also section 6.3 in [ElMasri & Navathe 89]).
  34. In any case, I don't have a "one-SQL-statement-solution" to your
  35. problem, either ...
  36.  
  37.  
  38. Paul Singleton's article was then followed up by
  39. jdr@starflight.Corp.Sun.COM (Jon Roland)  who writes in article
  40. <l8h5i5INNhvg@jethro.Corp.Sun.COM>:
  41. jr> You've missed our thread on "SQL Shortcomings", in which we have
  42. jr> shown why SQL is brain-damaged and needs to be stamped out.
  43.  
  44. I didn't follow that thread.  While I (again, see above) agree that
  45. SQL has its flaws ("brain-damaged" is a bit too strongly worded for
  46. my taste), you will certainly have a hard time to "stamp it out" --
  47. at least for the time being.  Even Mike Stonebraker, whose QUEL
  48. language design is regarded by most academics to be superior to
  49. SQL, has termed SQL "intergalactic data speak".  (Sorry, I don't
  50. remember where.)
  51.  
  52.  
  53. jr> Relational algebra allows expressions which have no SQL
  54. jr> equivalents, because SQL is not an implementation of relational
  55. jr> theory, and doesn't threaten to become one in the future.
  56.  
  57. An interesting statement.  Could you give me a few examples of
  58. relational algebra expressions which have no SQL equivalent?
  59. (Please only use operators from the set {selection, projection,
  60. union, difference, cartesian product}.  This set of operators
  61. has been shown to be complete.)
  62.  
  63.  
  64. jr> If you want to get some real work done, try something like
  65. jr> Progress.
  66.  
  67. I am not familiar with Progress.  However, I think that lots of
  68. people get plenty of real work done with SQL-based DBMSs, despite
  69. SQL's shortcomings.  (This is of course no reason that the
  70. researchers should not strive for better languages than SQL
  71. and for better data models than the relational data model.)
  72.  
  73. -- 
  74. Robert Marti                    |  Phone:    +41 1 254 72 60
  75. Informationssysteme             |  FAX:      +41 1 262 39 73
  76. ETH-Zentrum                     |  E-Mail:   marti@inf.ethz.ch
  77. CH-8092 Zurich, Switzerland     |
  78.