Sammansatta nycklar bör aldrig övervägas i "nya" applikationer. De användes förr, av människor som brukade tro att "affärsnycklar" är bättre än "surrogatnycklar".
Edit:Som Chris frågade, utökar jag mitt svar.
Låt mig börja med att säga att jag förstår denna fråga som "sammansatta primärnycklar" kontra "surrogatnycklar".
Jag medger också att det finns en användningsfall där en sammansatt nyckel är vettig:i korsreferenstabeller, även kallade "länktabeller". Dessa används i många-till-många-tabeller och består endast av två fält, båda främmande nycklar som utgör en primärnyckel för xref-tabellen. Till exempel UserRole Tabell skulle innehålla user_id och role_id , inget annat. Det finns ingen klassrepresentation i Java, till exempel, för en tabell som denna. Detta är vanligtvis en @ManyToMany , med en Collection på båda sidor.
Jag delade mina åsikter om naturliga nycklar vs surrogatnycklar i ett annat svar ( Hibernate :Åsikter i Composite PK vs Surrogate PK ) , och jag tror att Composite keys delar några av nackdelarna med den naturliga nyckeln, utan att ge någon verklig fördel.
Problemet med sammansatta nycklar är att du behöver två värden för att unikt identifiera en post. Detta blir ett problem när du börjar ha tabeller som refererar till poster i den här första tabellen. Den andra tabellen behöver då två kolumner för att kunna referera till en spela in. Och om den här andra tabellen använder en sammansatt nyckel som består av ett enda värde + den främmande nyckeln, har du nu tre kolumner för att unikt identifiera en spela in. Och ett tredje bord skulle behöva dessa tre extra kolumner bara för att referera till en rekord i den andra tabellen. Verkligen, det här är en snöboll.
En annan nackdel är att krav gör förändra. Hela tiden. Så vad som verkar vara en bra sammansatt nyckel idag är inte en nyckel alls i morgon. Det är därför vi har surrogatnycklar:att vara framtidssäker.
Sammansatta nycklar används huvudsakligen så att poster i en tabell är unika baserat på en uppsättning kolumner. Till exempel, om du har en Customers tabell kan du ha ett NationalId +Country som ett unikt värde, vilket innebär att två användare inte kan dela samma SSN om deras land är USA. Men det är möjligt att ha samma nummer för två skivor, om de inte är i samma land. Om du gillar sammansatta nycklar skulle detta vara en bra kandidat för det. Men som jag antydde tidigare kan du använda en surrogatnyckel och använda en unique begränsning. Du kommer att ha fördelarna med en sammansatt nyckel plus säkerheten med en surrogatnyckel.