home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11321 < prev    next >
Encoding:
Text File  |  1992-07-22  |  4.0 KB  |  97 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!odi!jack
  3. From: jack@odi.com (Jack Orenstein)
  4. Subject: Re: OO databases OBJECTSTORE vs ONTOS
  5. In-Reply-To: nh@cbnewsg.cb.att.com's message of Tue, 21 Jul 1992 07:47:43 GMT
  6. Message-ID: <1992Jul22.141451.4899@odi.com>
  7. Organization: Object Design, Inc.
  8. References: <1992Jul20.173530.28999@athena.mit.edu> <1992Jul21.074743.23542@cbfsb.cb.att.com>
  9. Date: Wed, 22 Jul 92 14:14:51 GMT
  10. Lines: 85
  11.  
  12. In article <1992Jul21.074743.23542@cbfsb.cb.att.com> nh@cbnewsg.cb.att.com (nicholas.hounsome) writes:
  13.  
  14.    From article <1992Jul20.173530.28999@athena.mit.edu>, by berczuk@space.mit.edu (Steve Berczuk):
  15.    > 
  16.    > Does anyone out there have any experiences with either Ontos or
  17.    > ObjectDesign;'s object store as a database for C++ objects? (even better, has anyone done any comparisions?)
  18.    > 
  19.  
  20.    I am currently doing a comparison - I have tried ObjectStore but I 
  21.    have not received a copy of ONTOS yet so I probably
  22.    know no more than you.
  23.  
  24. I'm an employee of Object Design, Inc.
  25.  
  26.    > what I know comparison wise (so far) is this (please correct me if I misstate anything):
  27.    > 
  28.    > *) Ontos seems to support a richer (and more SQL like if that is worth anything) query facility.
  29.  
  30.    That is my impression too. ObjectStore queries appear to be there 
  31.    for performance reasons only - to gain the advantage of indexing. They
  32.    are nothing like SQL. ObjectStore is very definitely for programmers
  33.    to make objects persistent rather than for ad hoc queries.
  34.  
  35. These are not mutually exclusive. ObjectStore is aimed at
  36. programmers developing applications that manipulate both
  37. transient and persistent objects. There is a non-procedural
  38. query language that can be used from the host programming
  39. language, (using our compiler or 3rd-party compilers), as well
  40. as from a browser.
  41.  
  42. The ObjectStore query language is not SQL, because SQL assumes a
  43. first normal form (1NF) schema, while object databases are
  44. almost never 1NF. The query language does some things that SQL
  45. cannot, (e.g.  support for user-defined types and functions,
  46. optimization of queries for some user-defined functions, support
  47. for non-first-normal-form constructs, queries over transient
  48. data), and vice versa, (e.g. dynamic type creation).
  49.  
  50. I agree with the statement that ObjectStore is "for
  51. programmers". So is SQL -- relational DBMS applications are
  52. built in a mixture of SQL and host language. ObjectStore
  53. simplifies this process by extending the type system of the host
  54. language to the database. This eliminates the need to translate
  55. back and forth between relational and host language type
  56. systems.
  57.  
  58.    > *) Ontos is inheritance based while Objectstore is not.
  59.  
  60.    I think that this is true. You can make anything persistent in
  61.    ObjectStore.
  62.  
  63. Correct. Persistence is treated as a storage class, rather than
  64. as an inherited behavior.
  65.  
  66.    > *) Object store has less effect on your code but is based on  language extensions
  67.  
  68.    You do not have to use the extensions. Talking to people on the 
  69.    course I went on most of them that either do not or will not use
  70.    the extensions. If you do not use the extensions then the only 
  71.    intrusion on your nonpersistent  C++ is:
  72.        a) stuff to handle database roots (entry points)
  73.            this can be handled by macros.
  74.        b) transaction handling.
  75.            this is obviously unavoidable.
  76.        c) stop gap exception handling macros pending
  77.            cfront support.
  78.        d) you must use ObjectStore collections if you want queries.
  79.        e) you must change all new calls for persistent allocation
  80.            Less trouble than you might think .
  81.  
  82.    Of these only (e) is realy noticeable.
  83.  
  84. To clarify: Some features of ObjectStore are supported as both
  85. language extensions, (available through a compiler provided as
  86. part of ObjectStore) and function-call interfaces. Other
  87. features are supported through a function-call interface only
  88. (because a language extension doesn't buy any simplification).
  89. All features are available through all supported interfaces.
  90.  
  91.  
  92. Jack Orenstein
  93. Object Design, Inc.
  94.  
  95.  
  96. -- This is not a disclaimer --
  97.