Re: [T] Clean Object Class Design -- What is it?

> topmind_at_technologist.com (Topmind) wrote in message
 news:<MPG.15b1a993c7091105989b5a_at_news.earthlink.net>...
> > > "Topmind" <topmind_at_technologist.com> wrote in message
> > > news:MPG.15b182bd93fe2c27989b51_at_news.earthlink.net...
>
> [snip]
>
> > > Any other experience to share with us, Bryce :-?
> > > Who put in all these newsgroups anyway? Added noise. Sorry.
> > > Bryce is our comp.object "cross to bear".
> > >
> >
> > There is plenty at oop.ismad.com
> >
> > -T-
>
> Topmind,
>
> I see you have a line on that page:
>
> "Myth: OODBMS are overall faster than RDBMS"
>
> Do you have some external references?

Nothing right now. Generally the material I saw indicates that OODBMs are faster at some things but slower at others.

Here is an excerpt from my webpages:

"Performance and Speed

Table joining (an SQL term) is nothing more than following a reference (ID or pointer). This is exactly what an OO system must also do. It is true that using the pointer/ID may require traversing an index, but indexes are to make things faster, not slower. Indexing is a way to find something without having to sequentially traverse a collection one-by-one. I confess that I do not know how indexing works in OODBMS (OO DB's) and OO collections, but if they found a better way than RDBMS, then the RDBMS companies would have already adopted it. (See the review of chapter 8 for a description of RAMbuffering.)  

I would note that the run-time structure that Meyer shows on page 227 is very relational in structure. Whether the data and links are stored in RAM or disk or a combo (caching) is mostly an implementation issue, not a paradigm issue.

There is nothing that says relational data cannot be processed in RAM, and usually is in part due to disk caching technology. My experience with XBase caching blurred the logical distinction I make between disk and RAM. Some commercial relational systems are even purposely designed and optimized to run in RAM. [I will try to insert some links later.]

The biggest distinction between relational and OO is how data is shared among paradigms (see above) and how closely algorithms are allowed to be tied to data. This has almost nothing to do with RAM versus disk. (OO also tends to be more hierarchical than relational, but this is also probably a minor issue with regard to performance.)

Many RDBMS enforce referential integrity rules, and other formal protection mechanisms. It is true that these sometimes consume a fair amount of processing. However, they are there to to improve reliability. Perhaps it would be nice if these protection mechanisms could be disabled when raw speed is needed. Note that I have used relational systems that lacked many of these mechanisms. (They were quite fast, but had occasional corruption problems if machines were turned off or malfunctioned in the middle of key processes.)

Another possible source of this false dichotomy is the fact that many OO systems use a simple linked list of pointers (object references) to model one-to-many relationships. This may make traversing the list quicker than doing a B-tree search via typical relational indexes for each entry on the "many" side. However, I see no reason why a relational system could not use a similar approach if B-trees are not satisfactory (for a given relationship). After all, the relationship between items (records) is often explicitly described to an RDBMS. Thus, it should have enough information to use a similar approach if the simple list approach has superior performance.

Somebody suggested that perhaps relational engines have been late to the RAM database market; thus they are still optimized for disk and caching instead of RAM. However, this is not a paradigm weakness, and may change over time.

One interesting theory put forth by Russell Wallace is that OODBMS emphasize a single aspect or single data access path at the expense of others. For example, if you have a hierarchical arrangement, the OODBMS may be faster. However, if you need other views or other relations in addition to the one hierarchy, then RDBMS may be faster. One can say that OODBMS may be more IS-A optimized while RDBMS are more HAS-A optimized. Perhaps RDBMS can be tuned to give priority to specific indexes and relations. However, this may have limited value in business applications, which tend to be HAS-A in structure. "

>
> [I have a Benchmarks page -
> www.soi.city.ac.uk/~akmal/html.dir/benchmarks.html -
> currently off-line due to web server maintenance, and I am always
> looking for new references to add]
>
> Thanks.
>
> akmal
>

-T- Received on Sun Jul 08 2001 - 19:10:51 CEST