home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / 7873 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.6 KB
  1. Xref: sparky comp.databases:7873 comp.databases.theory:613
  2. Newsgroups: comp.databases,comp.databases.theory
  3. Path: sparky!uunet!mcsun!chsun!bernina!neptune!nugget.inf.ethz.ch!marti
  4. From: marti@nugget.inf.ethz.ch (Robert Marti)
  5. Subject: Re: Simple SQL Join question
  6. Message-ID: <1992Nov16.091930.14764@neptune.inf.ethz.ch>
  7. Sender: news@neptune.inf.ethz.ch (Mr News)
  8. Nntp-Posting-Host: nugget.inf.ethz.ch
  9. Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
  10. References:  <1992Nov13.152835.1@ilp.mit.edu>
  11. Date: Mon, 16 Nov 1992 09:19:30 GMT
  12. Lines: 43
  13.  
  14. In article <1992Nov13.152835.1@ilp.mit.edu>, gold@ilp.mit.edu writes:
  15. |>     I have a basic SQL question regarding joins. [...]  A typical 
  16. |> query would ask for:
  17. |>         "List employee names and ids and each employee's
  18. |>          department(s), publication(s), project(s),
  19. |>          expertise keyword(s)
  20. |> Some employees have 10+ expertise keywords, 2-3 departments, 1-30 
  21. |> projects, 1-500 publications.
  22. |> 
  23. |> The SELECT statement that I am using is listed below.  [...]
  24. |> Is there a simplier, or less resource-consuming way of using SQL to 
  25. |> answer the user's question (in quotes above) rather than using the 
  26. |> SELECT statement below.  Thank you for any assistance!
  27. |> 
  28. |> SELECT  [...]
  29. |>   FROM  employee, employee_dept, dept, employee_project, project,
  30. |>         employee_publication, publication, employee_expertise, expertise
  31. |>   WHERE [ ... lots of join conditions deleted ...]
  32.  
  33. As David Masterson points out in his posting, you have practically
  34. no other choice than to issue separate queries (typically 3-way joins
  35. joining employee, employee_something, and something) and to "join"
  36. their results "manually", by writing a C-ESQL program, or by using
  37. some sort of 4GL (whatever that means) which supports the stuff you
  38. want.
  39.  
  40. Also, be aware that your SELECT-statement above will not return
  41. _any_ information on employees who have no corresponding information
  42. in _one_ of the tables joined with employee.  In this case, you'd
  43. have to use outer joins, a feature which was not in the 89 SQL
  44. standard.  (However, as far as I know, outer joins are supported
  45. by many systems.  Also, for what it's worth, I think outer joins
  46. made it into the 92 SQL standard.)
  47.  
  48. Your example is IMHO one of the biggest weaknesses of relational
  49. systems (or 1NF, if you will) as opposed to, for example, object-
  50. oriented systems.
  51.  
  52. -- 
  53. Robert Marti                    |  Phone:    +41 1 254 72 60
  54. Informationssysteme             |  FAX:      +41 1 262 39 73
  55. ETH-Zentrum                     |  E-Mail:   marti@inf.ethz.ch
  56. CH-8092 Zurich, Switzerland     |
  57.