Discussion :

[Ry_Yo]

Bonjour à tous,

J'ai eu récemment des remarques concernant de mauvaise habitudes que j'ai lorsque que je crée une base de donnée... Je voulais juste une explication claire afin de comprendre le pourquoi...

De manière systématique, lorsque j'ai une relation n-n entre 2 tables, je crée une clef composée ET un clef primaire...
Or on me dit que c'est une hérésie de crée une clef primaire, et que la clef composée est là pour ça...

Sur un exemple concret cela donne ceci :
- une table Nom (IdNom, Nom)
- une table Prenom (IdPrenom, Prenom)
- une table NomPrenom (IdNomPrenom, IdNom, IdPrenom, DateDeNaissance)

A la question pourquoi j'ai crée un IdNomPrenom ? La réponse est simplement par commodité... Lorsque plus tard je cherche un enreg pour un udpate ou delete... Je trouve ça plus commode (et plus rapide) de retenir dans l'appli un IdNomPrenom qu' IdNom+IdPrenom... surtout si ma clef composée et construite à partir de plus de 2 champs... Et je rajouterais aussi lors de traitement par lot d'enreg.. un IN(IdNomPrenom1,IdNomPrenom2,...) est, il me semble, plus facile à maintenir et comprendre... non ?

Bref... Merci de m'éclairer sur ce point.

[CinePhil]

Avec ton système, rien n'interdit au couple nom + prénom d'exister plusieurs fois, ce que apparemment tu ne souhaites pas.
Avec une clé primaire composée, ça n'arrivera jamais.

[Snipah]

En général, j'utilise également une clé primaire d'un seul champs numérique, et j'ajoute des contraintes d'unicité s'il y a lieu.

[Ry_Yo]

Mais si je garde mon exemple plus haut... et que je défini comme clef primaire composée "IdNom+IdPrenom+DateDeNaissance"

Est-ce que le fait de rajouter une clef primaire (simple) idNomPrenom est simplement disgracieux et fait double emploi avec la clef primaire composée, où y'a t'il un réel impact de performance ?

Parce qu'après au niveau requête (selon la complexité), je trouve que c'est fastidieux de se trainer tout le long 3 valeurs au lieu d'une (IdNomPrenom)....

[Snipah]

Deux clés primaires sur une même table?
Le sgbd va te jeter, utilise les contraintes d'unicité.

[Waldar]

J'ai tendance à rajouter une clef numérique lorsque je vais utiliser cette information dans d'autres tables.

Si c'est juste une table de corrélation (n,n), je laisse la clef naturelle.

Mais je ne pense pas qu'il soit possible (ni même judicieux) d'établir des règles d'or, l'important reste la cohérence et la qualité de vos données qui sont respectées dans les deux cas (avec une contrainte d'unicité supplémentaire si vous optez pour la clef non naturelle).

[Waldar]

Un petit article pas trop mal, mais en anglais :
http://decipherinfosys.wordpress.com...r-primary-key/

[CinePhil]

Un exemple classique qui montre qu'on peut passer du cas normal (clé primaire double) au cas dévié (identifiant + contrainte d'unicité) : l'association entre les commandes et les produits.
Mais on verra qu'en fait on transforme ici l'association en entité, ce qui justifie le passage au cas dévié.

Règle de gestion :
"Une commande contient de 1 à plusieurs produits et un produit peut faire partie de zéro à plusieurs commandes"

MCD :
Commande -1,n----Contenir----0,n- Produit

Tables :
Commandes (C_Id, ...)
Produits (P_Id, ...)
Contenir (CP_IdCommande, CP_IdProduit, CP_Quantite, ...)

Nouvelle règle de gestion :
"Une commande peut être livrée partiellement en raison d'une quantité de produit insuffisante en stock.
Une livraison concerne une à plusieurs lignes d'une commande en précisant à chaque fois la quantité."

Modification et complément du MCD :
Commande -1,n----Contenir----1,1- LigneCommande -1,1----Concerner----0,n- Produit
Livraison -1,n----Concerner----0,n-----------|

Modification et complément des tables :
Commandes (C_Id, ...)
Produits (P_Id, ...)
LigneCommande (LC_Id, LC_IdCommande, LC_IdProduit, CP_QuantiteCommandee, ...) avec contrainte d'unicité sur le couple (LC_IdCommande, LC_IdProduit)Livraison (L_Id, ...)
Concerner (LLC_IdLivraison, LLC_IdLigneCommande, LLC_QuantiteLivree, ...)