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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:QqP07.4099$2x1.51077255_at_radon.golden.net...
> >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.
>
> I disagree. It is possible using a single relational data base to capture
> employee information cogent and useful for all uses. Payroll may only
> interact with a small subset of the employee data, but the database can
> enforce rules required by HR and other applications.

By the same token, it is possible using a single object data base to capture employee information cogent and useful for all uses. This not a feature of relational or object oriented, but of good analysis and design.

> In one view of employee data, one might have a constraint that each
 employee
> is employed in a single department. In another view of employee data,
> additional relationships between employee and department may allow
 many-many
> cardinality with the employment relationship as a subset.

But you aren't suggesting that the constraint of being employed by a single department is view specific, are you? That is, in another view the constraint does not exist? Such a constraint is a database constraint, otherwise your database is doomed to inconsistency.

> OODBs do not handle such disparate views of the same data with anywhere
 near
> the same facility.

Well, in that if you use SELECT * in one view and SELECT * in another you might get different columns returned, I'd agree. However, since such code is broken as soon as the schema changes, I'm not sure what the point is. Nor do I understand on what basis you make such a sweeping generalization.

> >> >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.
>
> When the consultant denormalized the data, did the database still enforce
> all of the referential integrity constraints?

As I recall, the changes obviated some referential integrity constraints. It had to do with variable-length elements being replicated as "field1, field2,..." in a table.

> In what ways did the consultant denormalize? If he repeated data across
> multiple rows, would it not have been preferable to use physical
 clustering
> or physical redundancy without changing the logical view of the data?

Perhaps, but physical clustering was not an option.

> Would it not have been preferable to index the join without changing the
> logical view of the data? Could the database not have added a physical
> pointer to improve a lookup without changing the logical view of the data?

Perhaps, but the cost of indexing dwarfed other performance issues.

> The question is: Why should I have to change the logical view of the data
 to
> achieve the physical performance I require? Some vendors provide more
> physical independence than others, but even the best implementations fall
> far short of the mark.
>
> Why does everyone want to throw away the logical model just because
 vendors
> have failed to deliver on the physical side? Changing the logical model
 will
> only make things worse.

My favorite quote is attributed as Coggins' Law of Software Engineering: "Elegance must give way to pragmatics because Nature cannot be impressed."

Theory is great. Mathematical proofs are wonderful. But when you have real problems to solve, sometimes the ugly solution wins.

> >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.
>
> I would disagree with the above statement. I worked at a very large direct
> marketer whose business analysts were quite capable of correctly stating
> queries in the Sybase dialect of SQL. Unfortunately, Sybase failed utterly
> to deliver the results in the available time (days).

And I'm suggesting that there are data more complex than sales orders and payroll and other business-related constructs that are not so amenable to user 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.
>
> Again, I would ask whose fault this really is.

Laying the blame at the feet of your software vendor doesn't help much when your project fails to perform. No one wants excuses.

> >It is possible to like one tool without needing to destroy all others.
>
>
> Who is trying to destroy what?
>
> Even in an educated marketplace, it is possible for individuals to choose
 to
> use inferior tools for very specific uses. (Sometimes it really is faster
 to
> dig a hole with a spade than with a back-hoe.) Unfortunately, we do not
 have
> an educated market yet.

And you have yet to acknowledge that it is *possible* that an object database could be a superior tool for some applications. The gist of all your preceding posts is "ODBMS are all crap. Users of same are ignorant. The world would be a better place if they just got the true religion of relational." Received on Sun Jul 22 2001 - 01:33:38 CEST