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

"Bob Badour" <bbadour_at_golden.net> wrote in message news:ipr57.115$Dk4.38841462_at_radon.golden.net...
>
> 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.)

I checked the firstsql site and couldn't find anything (a search feature would be nice). But practically speaking, aren't multi-valued or string-based keys much slower than using integer values? I think a case could be made that almost any domain attribute would fail the "stability" test. Even contrived values like "Employee Number" or "Customer Number" are suspicious to me ;-). Someone told me once that you should always generate integer keys when using a RDBMS, but that was a long time ago, and maybe technology has improved since then.

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

I find SQL quite cumbersome in general. Fabian Pascal doesn't have much good to say about it either, but we are stuck with it. I think it may have a role for 3rd party access and reporting applications, but for application development I think a better alternative is needed.

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

My feeling is that SQL databases also require a lot of application code to keep duplication down, and some duplication is unavoidable without expert audits of the database. I was surprised to find that Oracle does not advocate 3NF (see http://www.firstsql.com/dbdebunk/fp4a.htm). One common mistake in building relational databases is using inappropriate keys. Once a mistake like that is made, it is really hard to go back and fix it. Maybe primary keys should never be used as foreign keys -- this sounds weird, but generated keys like OIDs are really useful for implementation issues like efficient Set operations and primary keys are really important for logical issues like uniqueness of values.

Maybe instead of "post-relational" people should be talking about "post-SQL". There are complete programming languages (like Smalltalk) that support declarative queries whose syntax can be much closer to that of relational algebra. The main advantage of SQL is that it is language-independent. You throw that away once you start using the embedded flavours of SQL, but the awkward syntax is even worse in those situations. Throw in cursors and you have a poor-man's XBase -- why not use a real language? ;-)

But more seriously, I had never heard of 5NF until I saw an earlier post you made -- do you have an online reference I can look at? My database textbook is rather old and only talks about BCNF and 4NF (Elmasri/Navathe 1989). One of the comments it makes (I just noticed this morning for the first time) is "Recent research in the relational model attempts to remove [restrictions on mult-valued and composite attributes] by using the concept of *non-first normal form* or *nested* relations." (their emphasis). 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? Does PostGreSQL (for example) support set-valued attributes? How does SQL deal with these things (and if non-standard extensions are required, why use SQL at all?).

Thanks for the feedback.

Cheers,
Steve (steve at wart dot ca) ICQ 50919689 Received on Thu Jul 19 2001 - 18:25:42 CEST