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

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

I have a pretty strong track record of delivering applications too, and I know some extremely productive programmers who don't have the first clue about databases or encapsulation, for that matter.

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

Any value-based key works just as well for these operations. Remember we are talking about a logical identifier, and one can achieve efficiency under the covers any number of ways.

>By assignment do you mean adding an object to a set?

No. I was just making sure you weren't using it to mean some kind of "Set variable = ..." assignment statement.

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

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

>I am not familiar with the term "set-at-a-time operations".

One can conceive of any number of operations that operate on sets of data but are not the mathematical operations of union, intersection etc. Relation assignment, for instance.

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

One has to remember that the definition is a logical definition that specifies the behaviour "as if" one performs cartesian product followed by restriction. In the same manner, one can define multiplication of natural numbers "as if" one performs repeated addition without implementing it that way.

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

It might be a very good application programming environment with SQL connectivity, but I would not consider it a DBMS.

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

If you use SQL. The problem lies in SQL's complete lack of support for domains (ie. object classes). By slightly increasing the complexity of the logical interface, one can query values in relation valued attributes.

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

The demand for domains (user-defined types) properly handled in the DBMS exists. I don't think anyone really questions that. Unfortunately, widespread ignorance and misconception cause people to assume that the deficiency lies in the relational model when it really lies in SQL.

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

Unfortunately, they made some huge fundamental mistakes in their implementation of inheritance. Inheritance applies to domains and not to relations.

The OID amounts to an exposed pointer, which is a huge mistake.

I do not like the way sequences are handled, but then again, I have had the same argument with people working on DB2.

Cheers,
Bob Received on Fri Jul 20 2001 - 02:25:37 CEST