Why single primary key is better than composite keys?

Question

Why is the rejection of composite keys in favor of all tables using a single primary key named id? Cause generally all ORM follow this.

EDIT

Answer 1

1. For an ORM a single identifying column with a consistent name like table_id is easier than a composite key. But every good ORM support composite keys.

2. An simple PK can easily be 'autoincremented' by the database. This doesn't hold for a composite key.

3. A simple PK is also easier to use in queries. When you need to join, you only have to use one column of both relations.

This is not to say that simple PKs are better than composite ones, though.

Answer 2

Objects in OO programming have identity regardless of their contents. Rows (tuples) in relational databases are identified by their contents only. So when really doing ORM, i.e. mapping objects from an object-oriented programming language to a relational database, an extra ID must be provided as distinct from the fields and/or properties the object has in the program - unless one or more of those are somehow known to identify objects uniquely.

Answer 3

Your question is strongly related to the surrogate (or artificial) keys vs natural keys alternative. I think it's not that composite keys are less used, but that natural keys (be them composite or simple) are less favoured than artificial keys.

Traditional relational database theory dealt mostly with "natural" keys, (the ones which have meaning from the business-domain point of view) and in that scenario composite keys are frequently found... naturally.

But in the later years, database design has favoured (though not exclusively) the "artificial" (surrogate) key pattern, typically a sequential number that has no business meaning, only serves to uniquely identifies the record in the table (and perhaps the object in the upper layer).