Discussion :

[Bernardos]

Bonjour,
J'ai l'habitude de toujours avoir une clé primaire technique auto incrémentée(identity) pour chaque table et je pense très sincèrement que c'est une très bonne habitude.
Cependant, je me pose la question pour les tables de liens comme l'exemple ci dessous

J'aurais tendance à aller systématiquement vers la solution 2, car la clé est plus petite mais je me dis que cette clé ne sera jamais utilisée en direct et que d'autre part, l'index cluster par défaut va etre sur idacces et qu'il semble qu'il serait plus utile sur la combinaison IDPERSONNE , IdSalle.
Quelle est votre avis sur la question. la solution 1 ou la solution 2?
quelles sont pour vous les avantages et inconvénients des 2 solutions.
Cordialement,

[escartefigue]

[...]mais je me dis que cette clé ne sera jamais utilisée en direct et que d'autre part, l'index cluster par défaut va etre sur idacces et qu'il semble qu'il serait plus utile sur la combinaison IDPERSONNE , IdSalle [...]

La réponse est contenue dans la question
Vu que ce nouvel identifiant n'est pas fonctionnel et qu'il ne sera référencé dans aucune contrainte d'intégrité, il ne sera jamais utilisé.
Donc une colonne de plus, pour rien

[SQLpro]

Après de multiples essais (il faudrait venir aux SQL Master Class qu'Orsys prépare avec un groupe d'expert dont je fait partit, pour en savoir plus...) sur le sujet, avec une clef composée de 2 colonnes INT, la conserver telle qu'elle est mieux que de la remplacer par une clef artificielle supplémentaire associée à une contrainte d'unicité... À 3 colonne c'est tangent... À quatre ou plus, cela devient indispensable sinon on alourdit trop les index non clustered...

Mais il faut faire attention à la composition de la clef qui peut être A, B ou B, A... !

A +

[Bernardos]

Merci pour les réponses.
4 mois plus tard me vient une question subsidiaire
Qu'en est il si on a des champs qui s'ajoute dans la table de liaison ?
genre dateModification,datecreation, Type d'accès, fonction,....(imaginons qu'il y en a 10)
Le raisonnement reste le même ?
à savoir

avec une clef composée de 2 colonnes INT, la conserver telle qu'elle est mieux que de la remplacer par une clef artificielle supplémentaire associée à une contrainte d'unicité... À 3 colonne c'est tangent... À quatre ou plus, cela devient indispensable sinon on alourdit trop les index non clustered...

Cordialement,

[SQLpro]

Oui, cela ne change rien à l'affaire !

A +

[StringBuilder]

Et que se passe-t-il si on doit mettre en place un héritage sur cette table de liaison ?

On se retrouve alors avec une clé étrangère ne portant plus sur une seule colonne mais bien deux (ou plus).

[SQLpro]

C'est une autre histoire !!!!

A +