Re: Separate PK in Jxn Tbl?

Hi Sylvain,

First, let me thank you for being so kind as to volunteer the information that you are a Most Vociferous Person (MVP). It does a fair service to the world when the self-aggrandizing ignorants self-declare that information.

Sylvain Lafontaine wrote:

> To that, I would add that the increased simplicity of using a surrogate (or
> artificial or autonumber) key as the primary key in place of a composite key
> is only half their advantage.

At this point, a prudent man would Plonk! you while mentally citing Date's _Principle of Incoherence_. Never the prudent man, instead, I observe the absurdity of your suggestion that adding features, structures or attributes increases simplicity. What nonsense!

> The biggest problem that I have with composite keys is that they share the
> same fundamental problem as natural keys: using them as the primary key is
> allowing the fact that a primary key can change its value over time. IMHO,
> a primary key should never be allowed to change its value once it has been
> created; a assumption which will forbid the use of a composite key in many
> cases.

I find your absolutism foolish suggesting ignorance and/or stupidity.

The design criteria for keys are: uniqueness, irreducibility, simplicity, stability and familiarity (in no particular order). If any criterion is absolute, it is uniqueness not stability.

   (Of course, if you don't mind to see a primary key changing its
> value after its creation then you are not concerned by this argument.).
>
> This is not only a theoritical argument as many interfaces - like Access -
> won't like to see a primary key that could change it value.

It is not a theoretical argument at all. You simply regurgitate ignorance and stupidity.

[remaining nonsense snipped]

Plonk! Received on Sat Jan 26 2008 - 17:58:23 CET