Les clés composites ne doivent jamais être envisagées dans les "nouvelles" applications. Ils ont été utilisés dans le passé, par des gens qui pensaient que les "clés d'entreprise" valaient mieux que les "clés de substitution".
Edit :Comme demandé par Chris, j'étoffe ma réponse.
Permettez-moi de commencer par dire que je comprends cette question comme "clés primaires composites" par rapport aux "clés de substitution".
Aussi, je reconnais qu'il y en a un cas d'utilisation où une clé composée a du sens :dans les tables de références croisées, aussi appelées "tables de liens". Celles-ci sont utilisées dans les tables plusieurs-à-plusieurs et consistent en seulement deux champs, les deux clés étrangères qui forment une clé primaire pour la table xref. Par exemple, UserRole la table contiendrait user_id et role_id , rien d'autre. Il n'y a pas de représentation de classe en Java, par exemple, pour une table comme celle-ci. Il s'agit généralement d'un @ManyToMany , avec une Collection dans les deux côtés.
J'ai partagé mon point de vue sur les clés naturelles par rapport aux clés de substitution dans une autre réponse (Hibernate :Opinions sur Composite PK vs Surrogate PK ) , et je pense que les clés composites partagent certains des inconvénients de la clé naturelle, sans apporter de réel avantage.
Le problème avec les clés composites est que vous en aurez besoin de deux valeurs pour identifier de manière unique un enregistrement. Cela devient un problème une fois que vous commencez à avoir des tables qui référencent des enregistrements dans cette première table. La deuxième table a alors besoin de deux colonnes pour pouvoir référencer une enregistrement. Et si ce deuxième tableau utilise une clé composée composée d'une seule valeur + la clé étrangère, vous en avez maintenant trois colonnes pour en identifier un de manière unique enregistrement. Et une troisième table aurait besoin de ces trois colonnes supplémentaires juste pour référencer une enregistrer dans le deuxième tableau. Vraiment, c'est une boule de neige.
Un autre inconvénient est que les exigences font monnaie. Tout le temps. Ainsi, ce qui semble être une bonne clé composée aujourd'hui ne l'est plus du tout demain. C'est pourquoi nous avons des clés de substitution :pour être à l'épreuve du futur.
Les clés composites sont principalement utilisées pour que les enregistrements d'une table soient uniques en fonction d'un ensemble de colonnes. Par exemple, si vous avez un Customers table, vous pouvez avoir un NationalId +Country comme une valeur unique, ce qui signifie que deux utilisateurs ne peuvent pas partager le même SSN si leur pays est les États-Unis. Mais il est possible d'avoir le même numéro pour deux enregistrements, s'ils ne sont pas dans le même pays. Si vous aimez les clés composites, ce serait un bon candidat pour cela. Mais comme je l'ai laissé entendre plus tôt, vous pouvez utiliser une clé de substitution et appliquer un unique contrainte. Vous bénéficierez des avantages d'une clé composite et de la sécurité d'une clé de substitution.
