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

Steve Wart wrote in message ...
>What should be used for a primary key in a relational design? Is it better
>to use real-world values (e.g. SSN, although this would only work for US
>employees) or is it better to generate a key?

Fabian Pascal once posted a comprehensive list of primary key selection criteria. I believe there were five elements to it, but I am not sure whether I remember it correctly:

Familiarity, Simplicity, Size, Generality, Stability ? I just cannot remember whether that's the list; although, at the moment, it seems close to me but perhaps not completely correct. (If Lee is watching, maybe he can ask Fabian for a refresher.)

>Does the RDBMS always create an index on a primary key to ensure
uniqueness?

Primary keys ensure uniqueness with or without an index. Some products automatically create an index as a general performance enhancement. Some products consider the table broken if it has a primary key and no index. One should note, however, that indexes will actually reduce performance for extremely small tables.

I find it annoying that SQL combines a logical constraint (uniqueness) with a physical structure declaration (create index).

>If this is the designer's responsibility, do all tables in a database
>generally have primary keys with uniqueness constraints defined, or is that
>"overkill" for practical purposes?

Unfortunately, this is going to depend on the DBMS brand to some extent. If the DBMS automatically creates an index for every PK, creating another index is just redundant. If the DBMS requires an index but doesn't automatically create one, the DBMS forces the designer's hand.

>How is generating a key better than the ODBMS equivalent of a
>system-generated Oid?

The non-relational ODBMS always creates the OID and requires one to use the OID whereas the relational ODBMS allows one to use a familiar key when available and appropriate.

The OID approach encourages designers to ignore other identifying attributes, which can sometimes lead to disastrous duplication. Received on Thu Jul 19 2001 - 04:07:27 CEST