home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / 6084 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  4.1 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!usc!news!lsi!mhost!cl301!ameesh
  2. From: ameesh@lsil.com (Ameesh Desai)
  3. Newsgroups: comp.databases
  4. Subject: Re: OODB Experiences/Opinions (Objectivity)
  5. Keywords: Objectivity, OODB
  6. Message-ID: <1992Aug12.181115.28185@lsil.com>
  7. Date: 12 Aug 92 18:11:15 GMT
  8. References: <bem.713575168@stone.NSD.3Com.COM>
  9. Sender: news@lsil.com (news caster)
  10. Reply-To: ameesh@lsil.com
  11. Organization: LSI Logic Corporation
  12. Lines: 88
  13. Nntp-Posting-Host: cl301
  14.  
  15.  
  16. In article 713575168@stone.NSD.3Com.COM, bem@ESD.3Com.COM (Evan McGinnis) writes:
  17. >My development group is starting to evaluate databases for OO
  18. >development and I would really appreciate some experiences/
  19. >opinions/testimonials.  
  20.  
  21. >We are looking at:
  22. >Versant, ObjectStore, Ontos and Raima*.
  23. >
  24.   ......
  25. >We have pretty much counted out relational DBs, as they
  26. >don't seem fit well into OO development.  (This is your
  27. >cue to let me know if I'm wrong here, and insert a 
  28. >testimonial about why you think XXX rdbms is perfect for OO
  29. >development)
  30.     Same here !
  31. >
  32. >>-Evan-
  33. >
  34. >--
  35. >------------------------------------------------
  36. >Evan McGinnis                   3Com Corporation
  37. >bem@3Com.com                    (408)764-6064
  38. >------------------------------------------------
  39.  
  40.  
  41.  
  42. We are in a similar situation. I shall give my opinion of what I have gathered from
  43. the varous marketing litrature regarding Objectivity.
  44. Could you post a summary of other replies/posts.
  45.  
  46. Objectivity : 
  47.     This has a concept of 'federated' databases, and seems to address the issues of 
  48.     distributing data accross hetrogenous platforms well. 
  49.  
  50.     However, to the best of my knowledge I found the following drawbacks ...
  51.     
  52.     1. It requires you to derive your persistent objects from its base class 
  53.         this raises a number of issues ...
  54.        - Do they have any virtual fns in that class, if so you pay the 4bytes for the
  55.          vtbl ptr.
  56.        - Do they need us to inherit that class as virtual ? In that you pay 4 more
  57.          bytes ! (this is to allow multiple inheritance).
  58.        - Can u create a non-persistent object of a class derived from their
  59.          base ? 
  60.     2. They overload the -> operator to be able to resolve the pointer addresses
  61.        i.e. if its on disk, bring it in on demand (it is a 'smart' ptr)
  62.        - Does this prevent us from using smart pointers in our code ?
  63.        - Every pointer derefrence will now have the overhead of checking if the 
  64.          address is real or on disk.
  65.        - as in C++ you can't overload the left side operator in a different manner
  66.          from the right side one - it does not know if you are updating the object
  67.          or just reading it.
  68.             i.e. x->y = z; 
  69.              and z = x->y; calls the same operator->, 
  70.          Thus they need us to add a call to mark an object 'dirty' everytime its
  71.          updated. This involves code change ! What about Class Libraries !!!
  72.     3. Their approach involves code change as shown by the requirements above.
  73.         - this is a major problem as one of the great advantages of OOP and C++ is
  74.           the availibility of class libraries and code re-use, I do not want to
  75.           understand the internals of the library in order to use its services ! 
  76.           I am even more reluctant to change library source - in some cases u will
  77.            not have access to the source !
  78.     4. They do not have a Query language.
  79.     5. They do not have Configuration Control.
  80.  
  81.  
  82. As you can see I have a number of issues that are not addressed well by Objectivity.
  83. Also I have a number of unanswered questions.
  84.  
  85. Any comments from Objectivity insiders ??? 
  86.  
  87. I should also mention that the above info is stuff I gathered thru marketing litrature
  88. that is now about a year old and things might have changed. 
  89.  
  90. Disclaimer: These opinions do not in any way reflect the official position of LSI
  91.             Logic, they are strictly my personal observations.
  92.  
  93.  
  94. Ameesh
  95.  
  96.  
  97. ---
  98. ______________________________     o__            
  99. | _   /|     Ameesh Desai     \    ,>/_                              
  100. | \`O.o'     LSI Logic Corp.   \__(_)`(_)_              email: ameesh@lsil.com
  101. | =(_|_)=    MS E192, 1501 McCarthy Blvd. \             fax  : (408) 433-6802
  102. |____U_______Milpitas, CA 95035____________\____________voice: (408) 433-4097 
  103.