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

From: Steve Wart <swart_at_deadspam.com>
Date: Thu, 19 Jul 2001 20:17:44 GMT
Message-ID: <IfH57.12805$h8.178061_at_news1.rdc1.bc.home.com>


"Bob Badour" <bbadour_at_golden.net> wrote in message news:0gF57.164$rT5.43127953_at_radon.golden.net...
>
> >Someone told me once that you should always generate
> >integer keys when using a RDBMS,
>
> Have you ever entertained the idea that the person was just a fool?

Well, he was in some ways. In other ways he was one of the smartest people I've ever met. He was quite successful at delivering applications, and I am generally impressed by people who get things done.

> >One common mistake in building relational databases is using
 inappropriate keys.
>
> I disagree. On what basis do you make such an extraordinary claim?

I confess, pure speculation. I was assuming that there are a lot of uninformed people out there using RDBMS technology, and therefore a certain percentage of those people will make bad design decisions. Maybe other bad decisions are so common that this one is rare in comparison.

> >generated keys like OIDs are really useful for implementation issues like
> >efficient Set operations
>
> Could you define what you mean by a Set operation? Are you referring to
> assignment, to set operators (union, intersection, join etc) or to
> set-at-a-time operations?

I am referring primarily to union, intersection, and difference operations, but also to membership tests. When I talk about Set operatons I am thinking of those defined in the Smalltalk Set and IdentitySet classes -- there is an ANSI spec but it is not available online. I think the Smalltalk definitions of these operations are reasonably compatible with those used in the relational model.

By assignment do you mean adding an object to a set? If set membership is defined based on equality (i.e. maintaining relational constraints) then these operations can be quite slow. If it is identity-based, then they can be done very quickly. As you suggest, the price to using identity-based set operations can be duplicated records, although if they are filtered out at presentation-time, the use of IdentitySet operations is an implementation detail.

I am not familiar with the term "set-at-a-time operations". I don't really think of join as a primitive set operation, but it could be added easily enough. The select: operation does not benefit from an IdentitySet implementation, however (and neither does cartesian product, although the mathematical definition of join as cartesian product followed by a select doesn't necessarily point to a reasonable implementation).

> > Why not use a real language? ;-)
 

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

> >In using GemStone/S for the past 10 years, I have come to depend on
> >the fact that I can have an object with a Set-valued attribute. How does
 your
> > position that the relational model subsumes the OO model address
 set-valued
> >attributes?
>
> All domains have internal structure. Domains can have or can be relation
values.

But if I use set-valued attributes I give up the ability to support external SQL queries? This has been my quandry: do I give up developer and application efficiency in order to support a rather dubious industry standard? Apparently the market says "yes". This is nutty. If there is an economic benefit to having support for these concepts, then the market will embrace it, as long as there is a path to acceptance. Either there is no economic benefit or the path is not there. Based on my experience of the past 10 years, I would say there is a benefit and (as crude as it is) SQL needs to be upgraded to support these concepts. Of course, maybe I am confused, and there is a version of SQL that supports the constructs needed to query an object database.

> >Does PostGreSQL (for example) support set-valued attributes?
>
> I doubt it. Does it support user-defined data types of any kind?

According to the FAQ (http://www.ca.postgresql.org/docs/faq-english.html): "PostgreSQL has most features present in large commercial DBMS's, like transactions, subselects, triggers, views, foreign key referential integrity, and sophisticated locking. We have some features they don't have, like user-defined types, inheritance, rules, and multi-version concurrency control to reduce lock contention."

I have no practical experience with this dbms, but it is open-source and easy to install. Windows users can install cygwin (http://www.cygwin.com), and it comes with the standard package.

p.s. I was mistaken re. Elmasri/Navathe -- they do indeed describe 5NF (Project-Join Normal Form) as well as Domain Key Normal Form.

--
Cheers,
Steve (steve at wart dot ca ICQ 50919689)
Received on Thu Jul 19 2001 - 22:17:44 CEST

Original text of this message