What is the general procedure for dealing with M:N relationships encountered during the process of database design?...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Are composite keys always a straightforward solution?
There is so much to be said on this subject, it's hard to decide where to start. Let's look at a simple example.
create table users ( id smallint not null primary key , name varchar(9) ) create table projects ( id smallint not null primary key , name varchar(9) ) create table userprojects ( userid smallint not null , projectid smallint not null , projectrole varchar(15) , primary key (userid,projectid) , foreign key (userid) references users (id) , foreign key (projectid) references projects (id) )
This is the same example used in another recent SQL answer, Inserting and searching many-to-many relationships.
Note that the relationship table USERPROJECTS has a composite key. Is this a straightforward solution? Yes. Is this the recommended way? Yes. Many database developers will automatically give this table a separate surrogate key (i.e. SEQUENCE, IDENTITY, AUTO_INCREMENT, etc.), but I do not.
The only time it makes sense to use a surrogate key is when the relationship table itself has child tables, and the child tables have many rows, and the queries using the child tables are complex. Relationship tables with child tables do occur, but they are rare. Unless you have a compelling reason, use composite keys.
And if you do decide to use a surrogate key for the relationship table, don't forget to declare a unique constraint on the composite anyway.
For More Information
- Dozens more answers to tough SQL questions from Rudy Limeback.
- The Best SQL Web Links: tips, tutorials, scripts, and more.
- Have an SQL tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize. Submit your tip today!
- Ask your technical SQL questions -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our SQL, database design, SQL Server, DB2, object-oriented and data warehousing gurus are waiting to answer your toughest questions.
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.