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

From: Steve Wart <swart_at_deadspam.com>
Date: Mon, 23 Jul 2001 22:03:51 GMT
Message-ID: <bb177.21697$zb.385594_at_news1.rdc1.bc.home.com>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:45r67.32$ZN7.10214417_at_radon.golden.net...
>
> >What features is GemStone lacking to be considered a DBMS?
>
> It's not the features it lacks that concern me. The unecessary features
 that
> pollute the logical model concern me.

Yes. It is a commercial product. Commercial products often contain features that make idealists uncomfortable. OTOH, I think that your reaction is a knee-jerk response to the fact that it is not a RDBMS, and hence is somehow "polluted". Are IDMS and IMS not DBMSs? Is SQL not polluted? It's fine to say that it does not provide a one-to-one mapping to your relational ideal, but that does not mean it does not satisfy the textbook definition of DBMS.

> >The Smalltalk model makes a distinction between identity (which is a
> >physical concept) and equality (which is a logical concept).
>
> I have to disagree with SmallTalk's model. Identity is a logical concept
 and
> not (necessarily) a physical concept.

It's just a definition within the language model.

> One can implement a relational database management system using just about
> any programming environment. I have no opinion regarding GemStone's
> suitability for this purpose; however, I did not see anything about
 GemStone
> that would provide it any advantage with regard to data integrity.

Transactions, rollback, coherent concurrency models. Things like that. As opposed to writing a RDBMS in C or Fortran, I suspect that time could be saved. A more relevant question would be whether any GemStone customers would be interested in using it as a relational database (the reaction I generally received is "why would I want to use a RDBMS when I can use GemStone?" -- note this is just the reaction I received, I don't really need an answer to that question).

It appears that your concerns about the use of ODBMS technology revolve around the issue of logical independence. But the relational vendors are capitulating to their customers and after 30 years, they come out with pointer chasing in SQL and recommendations to denormalize for performance. If this is the state of the art, then why not use an ODBMS (other than the fact that you need to support SQL for political reasons)?

The relational model looks great on paper, but I see no formal mechanism to map from an ideal logical representation to something that will perform well, other than providing developers with the tools they need to get the job done. Like anything, success depends on the intelligence and motivation of the people doing the work more than on the tools you give them. There is no magic bullet. Relational *technology* is not it. The relational *model* is a mathematical abstraction. OO has problems too, but it also helps deal with complexity in ways that the relational model cannot.

> >Minsky criticizes predicate calculus as being insufficiently expressive
 for
> >knowledge representation (see
> >ftp://publications.ai.mit.edu/ai-publications/0-499/AIM-306.ps).
>
> I had no joy with the link above.

Sorry for not warning you. The file is rather large (~8Mb) and has some postscript errors. I ran it through ps2pdf and it was fine. You likely will find no joy in the content either, as it is not a rigorous mathematical paper. If you are looking for a formal model of frame systems perhaps someone else can provide a link.

> >> Unfortunately, they made some huge fundamental mistakes in their
> >> implementation of inheritance. Inheritance applies to domains and not
 to
> >> relations.
> >
> >Why can inheritance not apply to relations as well?
>
> Because relations are sets and not object classes.

Relations are sets of tuples with uniform structure, correct? Can inheritance not apply to tuples?

--
Cheers,
Steve (steve at wart dot ca ICQ 50919689)
Received on Tue Jul 24 2001 - 00:03:51 CEST

Original text of this message