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

From: Steve Wart <swart_at_deadspam.com>
Date: Fri, 20 Jul 2001 05:45:37 GMT
Message-ID: <5AP57.16656$h8.249768_at_news1.rdc1.bc.home.com>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:_%K57.175$SK1.47657088_at_radon.golden.net...

> >
> >> Indeed. I suggest we overcome "impedance mismatch" by improving our
> >> application programming languages rather than retarding our DBMSs.
> >
> >An unlimited trail version of GemStone/S (the Linux version is free for
> >non-commercial use) is available at
> >http://www.gemstone.com/products/s/Linux/index.html. GemStone/Smalltalk
 is
> >IMHO the direction database programming languages should be headed. But
 it
> >is not SQL.
>
> It might be a very good application programming environment with SQL
> connectivity, but I would not consider it a DBMS.

GemStone is a programming environment that fully supports ACID transactions with optimistic and pessimistic concurrency models on a self-contained repository. SQL connectivity (in either direction) is not a fundamental.

What features is GemStone lacking to be considered a DBMS?

[...]

> >If set membership is defined based on equality (i.e. maintaining
 relational
> >constraints) then these operations can be quite slow.
>
> You are assuming a lack of physical independence.

This is a potential mechanism for the implementation of a relation. Independence is maintained at the conceptual level.

> >If it is identity-based, then they can be done very quickly.
>
> Becasue candidate keys provide identity, any method using them is identity
based as well.

> >As you suggest, the price to using identity-based set operations can be
 duplicated records
>
> Not if you correctly choose your identifier(s).

The Smalltalk model makes a distinction between identity (which is a physical concept) and equality (which is a logical concept). I agree that provisions should be made at the conceptual level for primary keys (if I understand your point correctly).

> >This has been my quandry: do I give up developer and
> >application efficiency in order to support a rather dubious industry
> >standard?
>
> I would suggest abandoning the dubious standard, SQL. However, I would
> abandon the standard by truly embracing the relational model.

How would you go about doing this? My preference would be to start with an environment like GemStone (where the bulk of the hard work around data integrity has been done already) and use it as an implementation basis for the relational model.

Another poster made reference to Alan Kay (who invented Smalltalk) and Marvin Minsky -- this is an interesting coincidence because the GemStone environment I worked with was essentially a frame system built in Smalltalk. However, I have not seen any papers that compare Minsky's frame systems to the relational model. This comparison would be interesting because relational calculus is often compared to predicate calculus and 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 have some reservations about the relational model because relations do not support the concept of a relationship; rather, relationships are expressed as queries outside of the database. I am somewhat heartened to learn that the relational model supports relation-valued domains, but I am concerned about using such domains to represent relationships. Do you have some references to expressions in relational algebra or relational calculus to give me a feel for how a query like this would be used?

> 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?

--
Cheers,
Steve (steve at wart dot ca ICQ 50919689)
Received on Fri Jul 20 2001 - 07:45:37 CEST

Original text of this message