Re: Clean Object Class Design -- What is it?

From: Jim Melton <jim.melton_at_lmco.com>
Date: Sat, 21 Jul 2001 23:33:16 GMT
Message-ID: <9ht1qt$2jh1_at_cui1.lmms.lmco.com>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:az307.3121$2N6.25501813_at_radon.golden.net...
> >Object modelling tends to worry about optimizing a handfull of
> >anticipated usages, those supported by method creation at coding time.
>
> I would go further and state that most, if not all, object models worry
> about a single application to the exclusion of all others.

While this may be true (I think it would be hard to substantiate such a generalization), it is not because of object models per se. It is just as easy to create single-use relational models.

> >Database design worries about making data optimally available for
> >ad-hoc queries.
>
> I would disagree with this statement. Database design worries about
 properly
> and effectively capturing the semantics and rules of the business.

Hmmm. You seem to be talking at cross purposes. Capturing the "semantics and rules of the business" seem like a single application to the exclusion of all others.

In any event, I disagreed with JRStern as well. No database design is optimal for ad-hoc queries. Optimization is added as required because it is expensive. All those indices take space.

> >I greatly prefer that the data come from a normalized database. The
> >objects can draw from complex queries. Let the server do a little
> >work, for gosh sakes! It pays off in the end.
>
> Again, I can wholeheartedly agree.
>
>
> >Where the database isn't normalized in the initial design, be assured,
> >significant system enhancement downstream will result from later
> >normalization.

In one application we worked on, the first thing our Sybase consultant did to increase performance was to de-normalize the database. I've heard several people claim that joins are not expensive, but my experience (at least) does not bear this out.

It is true that denormalization reduces the likelihood that your database can be exploited in heretofore unimagined ways, but sometimes the performance of the current application is the highest priority. Not all data will be subjected to ad-hoc queries. There are worlds beyond quarterly reports and graphs. With complex data, most users are not capable of creating cogent ad-hoc queries. In this case, you end up creating custom user interfaces which constrain the query and you are no longer ad-hoc at all.

It is possible to like one tool without needing to destroy all others. Received on Sun Jul 22 2001 - 01:33:16 CEST

Original text of this message