Under what condition we need to use composite keys in database

Question

i have seen that we can have composite keys where the primary key is made up from combined primary keys of two tables.

Like persons and Books

person_id a         


        

Answer 1

If you are storing a relation between person and books that is one-to-one (for example, perhaps you are running a website where users can rate books they've read on a scale of 1-5), then a composite primary key on the votes table of person_id and book_id makes just as much sense, if not more, as having a generated ID and a unique index on the combination of (person_id, book_id). The combination of the person and the book defines the vote record.

Answer 2

I cannot think of any conditions under which you NEED to use composite key. Some of the arguments Pro using a single id column include:
1. better indexing
2. simpler joins
3. easier to design guis
4. the fact that most ORMs work better with single field PKs (unfortunately)
5. easier to delete records

In your case although you can have a composite/surrogate key on person_id and book_id and it will be very useful, you can also have a single id column which CAN be your primary key also, but it does not have to be. You can use the person_id and book_id as PK or just an index, and same for id columns. The id column makes your life easier when deleting stuff or selecting single columns for view purposes. With today's RDBMS's where you normally don't have to worry about table size, it is advisable to include a single column - preferably auto increment identity columns to all your tables just in case it is needed. I believe it won't harm you in any way.

Answer 3

Surrogate keys are intrinsically bad and should be avoided at all costs. They make no sense in the real world. But sometimes they are necessary.

Leaving that aside for now, your example demonstrates exactly why composite keys are needed - more than one person can have a copy of a particular book - and a person can have more than one book - it's a N:M relationship. And representing this in a relational database is simple: you put another table in the middle with the PK of the book and the PK of the person.

id,person_id ,book_id

But (unless you want to cater for the scenario where you need to differentiate 2 copies of the same book owned by the same person, in which case the schema needs several other changes) since the combination of person_id and book_id is already unique, why do you need to another unique identifier which has no relevance to the data you are trying to model.

Answer 4

Composite keys should never be considered in "new" applications. They were used in the past, by people who used to think that "business keys" are better than "surrogate keys".

Edit: As asked by Chris, I'm expanding my answer.

Let me start by stating that I understand this question as "Composite Primary Keys" vs. "Surrogate keys".

Also, I concede that there is one use case where a composite key makes sense: in cross reference tables, also called "link tables". These are used in many-to-many tables and consists in only two fields, both foreign keys that form a primary key for the xref table. For instance, UserRole table would contain user_id and role_id, nothing else. There's no class representation in Java, for instance, for a table like this. This is usually a @ManyToMany, with a Collection in both sides.

I shared my views on Natural keys vs. Surrogate keys in another answer ( Hibernate : Opinions in Composite PK vs Surrogate PK ) , and I believe that Composite keys shares some of the disadvantages of the Natural key, without bringing any real benefit.

The problem with composite keys is that you'll need two values to uniquely identify a record. This becomes a problem once you start having tables which references records in this first table. The second table then needs two columns to be able to reference one record. And if this second table uses a composite key made up of a single value + the foreign key, you now have three columns to uniquely identify one record. And a third table would need these three extra columns just to reference one record in the second table. Really, this is a snow ball.

Another disadvantage is that requirements do change. All the time. So, what seems to be a good composite key today is not a key at all tomorrow. That's why we have surrogate keys: to be future-proof.

Composite keys are mainly used so that records in a table are unique based on a set of columns. For instance, if you have a Customers table, you may have a NationalId+Country as a unique value, meaning that two users cannot share the same SSN if their country is USA. But it's possible to have the same number for two records, if they are not in the same country. If you like composite keys, this would be a good candidate for it. But as I hinted earlier, you can use a surrogate key and apply a unique constraint. You'll have the benefits of a composite key plus the safety of a surrogate key.