Path: utzoo!utgpu!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: <Nov.29.13.51.19.1990.27566@caip.rutgers.edu>
Organization: Clear Communications, Inc.
Lines: 63

In article <Nov.29.13.51.19.1990.27566@caip.rutgers.edu> chappidi@caip.rutgers.edu (Rajendra Chappidi) writes:
>
>Is there a difference between the Object Oriented model and 
>Hierarchical Model at all or are they one and the same ?
>
>If any one has an answer to this please let me know.
>
>Thanks,
>Raj 

I am not an expert in this field, but I have been doing a _lot_ of
research into OODBMS in the last few months.  So here is an
amateur's point of view.

Object oriented databases store data in virtually the same manner
that a programmer keeps the data in memory.  Typically when a
programmer uses a database, he must read a group of data into
memory, massage that data somehow, and then perhaps write it
out again.  Sometimes the data structures used to keep the data
in memory are very compex (i.e. b-trees or circular buffers...)

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.  The OODBMS takes care of the rest.  The data is
stored on the disk in a manner which exactly represents the 
logical structure that the programmer builds in memory.  When the
program needs the data it simply makes a reference to the appropriate
memory location.  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.

Meanwhile the underlying OODBMS software handles all the problems
of data integrity, transaction rollback, distributed databases,
locking, etc...

The advantages to this technique are twofold (IMHO):  

	1).  Development time is significantly shortened since the 
		 developers do not have to deal with the concepts of getting
		 the data from disk, and putting the data back onto the disk.
		 The problem simply becomes one of what to do with the data
		 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.  OODBMSs are tools for software engineers who are
implementing systems with very complex types of data, and are not
currently interested in generating simple SQL reports.  

This subject deserves research.  As I said, I am simply an amateur,
and my information should be subject to some skepticism.

-- 
+-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for |
| rmartin@clear.com    |:R::R:C::::M:M:M:M:| my words but me.  I want  |
| uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all   |
+----------------------+:R::R::CCC:M:::::M:| the blame.  So there.     |