Композитните ключове никога не трябва да се разглеждат в "нови" приложения. Те са били използвани в миналото от хора, които са смятали, че "бизнес ключовете" са по-добри от "сурогатните ключове".
Редактиране:Както беше помолен от Крис, разширявам отговора си.
Позволете ми да започна, като заявя, че разбирам този въпрос като „Композитни първични ключове“ срещу „Сурогатни ключове“.
Също така признавам, че има един случай на употреба, при който съставният ключ има смисъл:в таблици за кръстосани препратки, наричани също „таблици за връзки“. Те се използват в таблици много към много и се състоят само от две полета, и двете външни ключове, които формират първичен ключ за xref таблицата. Например UserRole таблицата ще съдържа user_id и role_id , нищо друго. Няма представяне на клас в Java, например, за таблица като тази. Това обикновено е @ManyToMany , с Collection и в двете страни.
Споделих вижданията си относно естествените ключове срещу сурогатните ключове в друг отговор ( Hibernate:Мнения в Composite PK срещу Surrogate PK ) и вярвам, че композитните ключове споделят някои от недостатъците на естествения ключ, без да носят реална полза.
Проблемът със съставните ключове е, че ще ви трябват два стойности за уникално идентифициране на запис. Това се превръща в проблем, след като започнете да имате таблици, които препращат към записи в тази първа таблица. След това втората таблица се нуждае от две колони, за да можете да препращате към една запис. И ако тази втора таблица използва съставен ключ, съставен от една стойност + външния ключ, сега имате три колони за еднозначно идентифициране на един запис. И трета таблица ще се нуждае от тези три допълнителни колони само за препратка към една запис във втората таблица. Наистина, това е снежна топка.
Друг недостатък е, че изискванията изпълняват промяна. През цялото време. Така че това, което днес изглежда като добър съставен ключ, утре изобщо не е ключ. Ето защо имаме сурогатни ключове:за да бъдем надеждни за бъдещето.
Композитните ключове се използват главно, така че записите в таблицата да са уникални въз основа на набор от колони. Например, ако имате Customers таблица, може да имате NationalId +Country като уникална стойност, което означава, че двама потребители не могат да споделят един и същ SSN, ако тяхната страна е САЩ. Но е възможно да имате един и същ номер за два записа, ако не са в една и съща държава. Ако харесвате композитни ключове, това би бил добър кандидат за него. Но както намекнах по-рано, можете да използвате сурогатен ключ и да приложите unique ограничение. Ще имате предимствата на съставен ключ плюс безопасността на сурогатен ключ.
