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

Forwarded response from Fabian Pascal...

Bob Badour wrote:
>
> 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.)

UNDERSTANDING RELATIONAL DATABASES p.48: familiarity, stability, minimality, simplicity.

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

PK ought to ensure uniqueness with and without an index, but I am not aware of any product which does not implement PKs by indexing.

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

OIDs, unlike PKs, they are not values, but pointers. Logical ones, but pointers nevertheless, with all the drawbacks.

--
Fabian Pascal, editor_at_dbdebunk.com