home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / clients / 181 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  3.2 KB

  1. Path: sparky!uunet!paladin.american.edu!auvm!ksadegh
  2. Organization: The American University - University Computing Center
  3. Date: Thu, 19 Nov 1992 14:05:31 EST
  4. From: Kayvon Z. Sadeghi <KSADEGH@auvm.american.edu>
  5. Message-ID: <92324.140531KSADEGH@auvm.american.edu>
  6. Newsgroups: comp.client-server
  7. Subject: Re: SQL and Client-server architecture
  8. References: <92316.105420KSADEGH@auvm.american.edu>
  9.  <1992Nov17.160748.5948@cbnewsl.cb.att.com> <paul.722141311@suite.sw.oz.au>
  10. Lines: 62
  11.  
  12. In article <paul.722141311@suite.sw.oz.au>, paul@suite.sw.oz.au (Paul Antoine)
  13. says:
  14. >
  15. >In <1992Nov17.160748.5948@cbnewsl.cb.att.com> sdo@cbnewsl.cb.att.com
  16. >(scott.orshan) writes:
  17. >
  18. >>In article <92316.105420KSADEGH@auvm.american.edu> Kayvon Z. Sadeghi
  19. ><KSADEGH@auvm.american.edu> writes:
  20. >>>I was wondering why all the client/server systems use SQL as their
  21. >manipulation
  22. >>>language. I don't recall seeing any client/server that works on OO or
  23. >>>hierarchy, for example. Is this because its easier to implement             s
  24. >client/server
  25. >>>in SQL or is there any especial reason.
  26. >
  27. >>I'm not sure why you say that all client/server systems use SQL.
  28. >>Perhaps all client/server SQL database systems use SQL (a tautology),
  29. >>but some databases don't, and non-database client/server packages
  30. >>probably have no need to use SQL.
  31. >
  32. >>For example, plain RPCs and TP Monitor C/S calls pass arbitrary information
  33. >>between clients and servers.  Most client/server access is probably
  34. >>just remote file access, and that has nothing to do with SQL.
  35. >
  36. >And I'd even dispute that most C/S access is not remote file access (as in
  37. >our C/S system that talks to 3270-based applications).  The TP monitor is
  38. >used to route the data, and is aware of the type and number of servers and
  39. >where they're running, but there's no restriction on the data (i.e. it
  40. >needn't be SQL!).
  41. >
  42. >The confusion probably arises because most C/S systems are used to more
  43. >efficiently access corporate data - but this needn't be in the form of
  44. >direct database access.  A lot of it can also be done through existing
  45. >applications (as in our case).  It just goes to show that getting consensus
  46. >on the eternal question 'what is C/S?' is well nigh impossible,
  47. >
  48. >Regards,
  49. >Paul (a Tuxedo fan)
  50. >
  51. >------------------------------------------------------------------------------
  52. >Paul Antoine, Softway Pty Ltd                       Net: paul@suite.sw.oz.au
  53. >PO Box 305, Strawberry Hills, NSW 2012, Australia   Tel: +61 2 698 2322
  54. >79 Myrtle St, Chippendale, NSW 2008, Australia      Fax: +61 2 699 9174
  55. >------------------------------------------------------------------------------
  56.  
  57.  
  58. Perhapse I didn't clear myself, at least not good enough. What I meant was
  59. why most of the client/server *data bases* use SQL. My appologies.
  60. I know that some of the client/servers are not data bases, e.g. file servers
  61. or printer servers have nothing to do with data base. So, I guess, I
  62. should be more careful in future.
  63.  
  64.  
  65. k1
  66. ---
  67. ------------------------------------------------------------------------
  68. PUSH, if that doesn't work
  69. PULL, if that doesn't work
  70. we're probably CLOSED
  71. ------------------------------------------------------------------------
  72. Kayvon Sadeghi                    k.sadeghi@ieee.org
  73. Voice:202/244-0789
  74.