Re: Separate PK in Jxn Tbl?
Date: Sat, 26 Jan 2008 12:58:23 -0400
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
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