UtterAccess HomeUtterAccess Wiki

Welcome Guest ( Log In | Register )

Custom Search
Edit Discussion
> Composite Indexes vs Composite Primary Keys    
(Difference between revisions)
Revision as of 01:47, 10 February 2012
Jleach (Talk | contribs)
(added Normalization category)
← Previous diff
Revision as of 16:24, 12 October 2013
DatAdrenaline (Talk | contribs)

Next diff →
Line 4: Line 4:
{{DebatableBox|The subject of Natural keys versus Surrogate keys is much debated. Please help us by including both viewpoints with each method's pros and cons in the [[Natural Vs Surrogate Keys]] article.}} {{DebatableBox|The subject of Natural keys versus Surrogate keys is much debated. Please help us by including both viewpoints with each method's pros and cons in the [[Natural Vs Surrogate Keys]] article.}}
-You will often hear that '''Composite''' or '''Multi-field Primary Keys''' is a poor design technique and usually violates the 1st normal form of Normalization.{{Debatable}}+You will often hear that '''Composite''' or '''Multi-field''' Primary Keys is a poor design technique. The reasons varied for this claim, much of those arguments center around complication with respect to building referential integrity and joining sources in queries. There are other reason for the debate, but ultimately each developer needs to understand that composite keys are not a design flaw or an automatic violation of normal form guidelines. By the same token, surrogate keys are equally not a design flaw or violation of normal forms either.{{Debatable}}
Typically it is recommended to use a '''Composite Index''' instead to accomplish the effect of the combination of 2 or more fields to create a unique record. Typically it is recommended to use a '''Composite Index''' instead to accomplish the effect of the combination of 2 or more fields to create a unique record.

Revision as of 16:24, 12 October 2013

Composite Indexes vs Composite Primary Keys

This page is a stub. Please help us by expanding or merging it with applicable content

Debatable Content

The subject of Natural keys versus Surrogate keys is much debated. Please help us by including both viewpoints with each method's pros and cons in the Natural Vs Surrogate Keys article.

You will often hear that Composite or Multi-field Primary Keys is a poor design technique. The reasons varied for this claim, much of those arguments center around complication with respect to building referential integrity and joining sources in queries. There are other reason for the debate, but ultimately each developer needs to understand that composite keys are not a design flaw or an automatic violation of normal form guidelines. By the same token, surrogate keys are equally not a design flaw or violation of normal forms either.[debatable]

Typically it is recommended to use a Composite Index instead to accomplish the effect of the combination of 2 or more fields to create a unique record.

The problem is it's not often explained how. The attached db does just that. It walks you through the design and functionality of the following:

  • Composite PK
  • Adding an Autonumber Field
  • Autonumber primary key and a Composite Index.

Media:CompositeIndexExample.zip
Media:CompositeIndexExample97.zip



This page was originally ported from the UtterAccess Forums. It is based heavily or in part on a post by J.D..
Composite Indexes vs. Composite Primary Keys

Edit Discussion
Custom Search


Thank you for your support!
Disclaimers