Règle sur le choix d'une clé primaire dans une table - SQL/NoSQL - Programmation
Marsh Posté le 09-06-2004 à 10:01:55
Non ! Ce qui fait une clé primaire c'est son unicité ! Donc si tu créer un identifiant tu résoud le problème. Par contre tu peux aussi prendre la solution du plusieurs champs qui créer cette clé primaire de ta table. Tu choisis ces champs en fonction de la logique.
Par exemple:
Un code client est forcément unique, un code facture aussi ou un code d'enregistrement.
Par contre un montant ou un champ commmentaire peuvent apparaitre plusieurs fois avec le même enregistrement ce qui créerai des doublons (situation impossible pour une clef primaire).
Pour résumer, une clef primaire doit être unique !
Voila j'espère avoir répondu assez clairement à ta question.
Marsh Posté le 09-06-2004 à 10:29:28
ok merci je pense avoir savoir comment le réexpliquer maintenant
Marsh Posté le 09-06-2004 à 13:57:06
en général, une clé est composée de plusieurs champs quand on a une table qui stoque des infos relatives au croisement de plusieurs tables.
exemple :
- id_client est la clé de la table client
- id_commande est la clé de la table commande
- la combinaison id_client, id_commande peut être utilisée comme clé d'une table appelée commande_client qui stoque les infos relatives au client et à la commande. Par exemple l'adresse de livraison pour cette commande, qui peut différer de l'adresse par défaut qui elle, pourrait être stoquée dans la table client.
Marsh Posté le 09-06-2004 à 16:31:07
ok là ça m'aide encore plus pour expliquer le pk du comment, merci
Marsh Posté le 09-06-2004 à 09:11:23
Voilà je me posais une question, pour identifier de manière unique un enregistrement sur une table on se base très souvent sur une clé primaire identifiant par exemple qui ne laisse aucune ambiguité. Mais au boulot j'ai souvent rencontré des cas où l'on n'a pas cet identifiant mais une combinaison de clé.
mais dans cette combinaison de clé moi je vois surtout des champs de type numérique entier comme un code client, un code facture, un code d'enregistrement, etc... je ne sais pas pourquoi mais je prendrai pas par exemple un champ commentaire et/ou un champ montant par exemple pourtant techniquement ça marcherai aussi si ce sont des champs qui une fois établit ne peuvent être modifier non?