Path: utzoo!attcan!telly!problem!compus!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!cpsc.ucalgary.ca!news From: gintera@cs-sun-df.cpsc.ucalgary.ca (Andrew Ginter) Newsgroups: comp.databases Subject: Re: Object Oriented Model and Hierarchical Model Keywords: Difference Message-ID: <1990Dec14.180355.23444@cpsc.ucalgary.ca> Date: 14 Dec 90 18:03:55 GMT References: <1990Dec1.233829.21645@clear.com> Organization: U. of Calgary Computer Science Lines: 61 Nntp-Posting-Host: cs-sun-df Article 1274 of comp.databases: Path: cpsc.ucalgary.ca!arcsun.arc.ab.ca!alberta!ubc-cs!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!motcsd!mcdcup!mcdhup!mcdchg!tellab5!balr!clrcom!rmartin From: rmartin@clear.com (Bob Martin) Newsgroups: comp.databases Subject: Re: Object Oriented Model and Hierarchical Model Keywords: Difference Message-ID: <1990Dec1.233829.21645@clear.com> Date: 1 Dec 90 23:38:29 GMT References: Organization: Clear Communications, Inc. Lines: 63 rmartin@clear.com (Bob Martin) writes: > Object oriented databases store data in virtually the same manner that > a programmer keeps the data in memory. > > ... > > When using an object oriented database, the programmer can _forget_ > about reading the data into memory or writing it out again later. > (S)He simply massages it as though it were already in his internal > data structures. ... Something akin to a virtual memory page fault > brings the programmers data into memory and relocates any pointers so > that from the programmers point of view, the data is simply sitting in > memory. > > ... > > 2) Access to data is _very_ fast. You can get benchmarks from > some of the OODBMS vendors, but the upshot of it all is that > they are "screamers". > > You should know that OODBMS is not a panacea. There is no standard > query language (like SQL). Typically no forms packages or QBF type > facilities. These were impressions I too had when I first started investigating this subject, but the impressions are misleading. Right now, there are two kinds of object database: "persistent object stores" and "extended relational databases". The former tends to store information in the database in "virtually the same manner as the programmer keeps data in memory", and the latter tends to be built on relational database technology. Many, but not all, of both kinds of these databases are equipped with a cache manager which caches objects in application memory. As for performance, it is the cache manager that makes the difference. Object caches really shine in applications requiring navigational access to the database. However, in traditional data processing or transaction management applications, caches may actually slow things down slightly. Finally, most of the commercial and the big research object databases support a declarative query facility. In addition, many are implementing all sorts of graphical interfaces ranging from graphical query languages to graphical database definition and manipulation languages, though I don't know if any of them yet support the equivalent of a 4GL. Andrew Ginter, 403-282-2984, gintera@cpsc.ucalgary.ca