The Database Design Resource Center


composite primary key

hdr table PK - > hdr ID
item table PK - > item ID

Line table PK -> hdr ID , item ID

This will create several issues. In my opinion, every table should have a unique ID within the system , which is not a business data , like ACC Number etc. Otherwise we are making a rigid system.

Comments for Trainee

Average Rating starstarstarstar

Click here to add your own comments

Oct 05, 2015
Review NEW
by: Anonymous

Educator learners need to comprehend why understudies learn in diverse styles, and must suit to address each issue. As in any general public, we meet up as one to unite the world in comprehension and resilience. someone write my essay. By having those, anybody, including educator learners will have a superior comprehension of the social perspective in which is instruction.

Aug 07, 2015
Good post NEW
by: Will Kub

Thanks for your brilliant articles! Your niche site is great!
May I publish your article on my site?
I will link for you as an author of this article!

Many thanks for answering!

Jun 27, 2015
Education NEW
by: Anonymous

The significance of the work of research is increasing and expanding. The skills are provided by the mature and they are refined and polished to write my paper by the system of education.

Jan 04, 2012
Wrong NEW
by: Anonymous

If your point is that multi-column primary keys are wrong, and every table should have an generated key, then you definitely need to learn more about what a key is (actually what relational model is). I suggest you to get a theory book.

Jan 02, 2009
Not so fast
by: Aaron Bingham

I completely disagree. You don't need to add a numeric ID unless you have an external requirement for one (except for rare exceptions, see below).

You must define at least one key for every table (unique constraint or primary key). This key can span multiple columns. Often, the key _must_ span multiple columns because of the nature of the data. If you cannot identify such a key, you don't understand your data yet. Study it again.

Overuse of surrogate keys can cause you trouble when:
* you forget to define any other keys (unique constraints) on the real data and you end up with duplicate data
* you are forced to perform many unnecessary joins, complicating queries and degrading performance
* you lack data from the key in a referring table that would allow definition of better constraints
* etc.

A numeric surrogate key (a key which does not arise from the external requirements) can be considered in certain circumstances exceptional circumstances. Cases where you might consider a surrogate key are:
* when a concrete performance bottleneck has been identified which cannot be addressed by other means (e.g., defining an index)
* when writing queries proves too cumbersome
* when repeating multiple columns of the key in referring tables threatens to cause a maintenance headache.
Don't jump into this too fast.

Click here to add your own comments

Join in and write your own page! It's easy to do. How? Simply click here to return to Worst Database Design Experience.

Exclusive interviews with:
Steven Feuerstein, PLSQL expert
Donald Burleson, Top IT consultant

Free eBook

Subscribe to my newsletter and get my ebook on Entity Relationship Modeling Principles as a free gift:

What visitors say...

"I just stumbled accross your site looking for some normalization theory and I have to say it is fantastic.

I have been in the database field for 10+ years and I have never before come across such a useful site. Thank you for taking the time to put this site together."

Mike, USA

Read more Testimonials

Database Normalization eBook:

Database Normalization eBook

Copyright © / Alf A. Pedersen
All rights reserved.
All information contained on this website is for informational purposes only.
Disclaimer: does not warrant any company, product, service or any content contained herein.

Return to top

Copyright acknowledgement note:

The name Oracle is a trademark of Oracle Corporation.
The names MS Access/MS SQL Server are trademarks of Microsoft Corporation.
Any other names used on this website may be trademarks of their respective owners, which I fully respect.