home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11207 < prev    next >
Encoding:
Text File  |  1992-07-20  |  2.4 KB  |  69 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!cs.utexas.edu!convex!linac!att!cbfsb!cbnewsg.cb.att.com!nh
  3. From: nh@cbnewsg.cb.att.com (nicholas.hounsome)
  4. Subject: Re: OO databases OBJECTSTORE vs ONTOS
  5. Message-ID: <1992Jul21.074743.23542@cbfsb.cb.att.com>
  6. Sender: news@cbfsb.cb.att.com
  7. Organization: AT&T
  8. References: <1992Jul20.173530.28999@athena.mit.edu>
  9. Date: Tue, 21 Jul 1992 07:47:43 GMT
  10. Lines: 57
  11.  
  12. From article <1992Jul20.173530.28999@athena.mit.edu>, by berczuk@space.mit.edu (Steve Berczuk):
  13. > 
  14. > Does anyone out there have any experiences with either Ontos or
  15. > ObjectDesign;'s object store as a database for C++ objects? (even better, has anyone done any comparisions?)
  16. > 
  17.  
  18. I am currently doing a comparison - I have tried ObjectStore but I 
  19. have not received a copy of ONTOS yet so I probably
  20. know no more than you.
  21.  
  22. > what I know comparison wise (so far) is this (please correct me if I misstate anything):
  23. > 
  24. > *) Ontos seems to support a richer (and more SQL like if that is worth anything) query facility.
  25.  
  26. That is my impression too. ObjectStore queries appear to be there 
  27. for performance reasons only - to gain the advantage of indexing. They
  28. are nothing like SQL. ObjectStore is very definitely for programmers
  29. to make objects persistent rather than for ad hoc queries.
  30.  
  31. > *) Ontos is inheritance based while Objectstore is not.
  32.  
  33. I think that this is true. You can make anything persistent in
  34. ObjectStore.
  35.  
  36. > *) Object store has less effect on your code but is based on  language extensions
  37.  
  38. You do not have to use the extensions. Talking to people on the 
  39. course I went on most of them that either do not or will not use
  40. the extensions. If you do not use the extensions then the only 
  41. intrusion on your nonpersistent  C++ is:
  42.     a) stuff to handle database roots (entry points)
  43.         this can be handled by macros.
  44.     b) transaction handling.
  45.         this is obviously unavoidable.
  46.     c) stop gap exception handling macros pending
  47.         cfront support.
  48.     d) you must use ObjectStore collections if you want queries.
  49.     e) you must change all new calls for persistent allocation
  50.         Less trouble than you might think .
  51.  
  52. Of these only (e) is realy noticeable.
  53.  
  54. > *) ODI sales reps seem to not return calls 
  55. > 
  56.  
  57. Their distributors in the UK are good (but then they are only 15 minutes
  58. drive away) and one of the founders at least seems keen to deal with
  59. problems promptly.
  60.  
  61. > Any comments would be appreciated,,, thanks,
  62. > steve berczuk
  63. > 
  64.  
  65. Please keep me informed of your investigations,
  66.  
  67. Nick Hounsome
  68.  
  69.