Salut,
 
Quand j'essaye de mettre l'attribut auto_incrment, je suis OBLIGER D'AJOUTER PRIMARY KEY à la fin de la requête...
Je sais pas à quoi ça sert, avez-vous des liens ? Merci
 

une clé primaire (PRIMARY KEY) permet de définit un champ qui permet de définir de manière unique les enregistrements.
Par exemple la primary key pour un voiture ca peut etre la plaque d'immatriculation.
 
Je sais pas si j'ai ete clair mais bon

Si très clair,
 
Et si je comprends, on choisi souvent le champ ID qui est incrémenté, car comme il est incrémenté à une valeur différente à chaque fois, tu confirmes ?

Oui !

Il faut savoir qu'une clé primaire peut aussi être constituée de plusieurs champs.
 
Genre pour la gestion d'un stock, la clé primaire sera le couple "produit, hangar"

ok

Salut je viens dire mon mot
mes réflexions m'ont amené à la conclusion qu'une clé primaire ne devrait jamais etre constituée de plusieurs colonnes, parce que ca complique tout après. Une clé mprimaire constituée d'une seule colonne est bien plus efficace et simple à gérer et à faire évoluer.

D'accord avec la dernière phrase, mais pas avec la première. Des contraintes d'intégrité peuvent de pousser à utiliser une clé primaire composée, cf exemple de MagicBuzz.
 
Sinon, que pensez-vous d'une clé primaire composée uniquement ou en partie d'une clé étrangère ? Est-ce déconseillé ou il n'y a rien d'anormal à cela ?
 
Krueger

personnellement je rajoute systématiquement une primary key à toutes mes tables, memes celles d'allocation (ne contenant que des secondary key)
on m'a toujours dit que c'était mieux, confirmez-vous?

 
a quoi ca sert d'avoir deux tables alors

 
je comprends pas? c'est quoi?

par exemple j'ai une table personne, une table club, et une table "appartient à", avec la clé primaire de personne et la clé primaire de club.
je sais jamais quel est le bon terme

euh oui, je vois... je me rappelle plus comment ça s'appelle. par contre, dans ces cas je met la clé primaire sur les deux foreign key.

En effet, après réflexion tu as raison. J'y étais allé un peu vite.
 

Ça permet au moins d'éviter les doublons indésirables.

Ca ne sert à rien, uniquement à te compliquer la vie si justement tu ne fait pas un index unique (ou une contrainte d'unicité) sur les deux clés étrangères.
 
Avec MySQL au début il y avait en effet un avantage à n'avoir qu'un champ comme clé primaire, puisqu'il ne supportait qu'un champ comme clé primaire... Mais ça fait un bail que cette limitation n'existe plus, donc ça ne sert rigoureusement à rien.
 
PS: ça fait un moment déjà que sur les SGBD récents on ne raisonne plus en clé primaire, mais en index unique. En effet, ça revient au même niveau select performances des select, mais les perfs sont globalement meilleures, et surtout c'est plus aisé à faire évoluer. Deplus, on trouve souvent des tables qui ont plusieurs clés primaires, hors très peu de SGBD supportent plusieurs clés primaires sur une même table. Les index uniques permettent de faire sauter cette limitation.
 
Exemple :
 
Table produit :
 
CODE_PRODUIT
CODE_SAP
CODE_BARRE
NOM
 
On a trois clés primaires, et y'en a pas une mieu que les autres.
 
CODE_PRODUIT : Code interne, généralement un auto-incrément.
CODE_SAP : Code du produit dans l'ERP SAP, sur lequel est peut-être plugée l'appli.
CODE_BARRE : Code barre écrit sur l'étiquette du produit.
 
Dans ce cas, on fera un index unique sur chacun des trois champs.
 
Mais on peut aussi avoir des tables plus complexes...
 
Détail de commande :
 
COMMANDE_ID
LIGNE_NUMBER
CODE_PRODUIT
...
 
Dans ce cas, on a deux clés primaires possible :
COMMANDE_ID, LIGNE_NUMBER et COMMANDE_ID, CODE_PRODUIT (dans le cas où un produit ne puisse être que sur une seule ligne d'une même commande, ce qui n'est pas toujours le cas)
 
Donc là on va avoir droit à deux clés primaires composées de couplets. Une fois de plus, un index unique permettra de gérer cette double clé primaire et la présence de deux champs membres de la clé, et ce, sur n'importe quelle base de données, alors que le support de tels clés primaires n'est pas toujours supporté.

lol ,j'ai fait couler de l'encre, enfin des octets...
Je vous en remercie car j'apprends !

Moi aussi j'ai appris du post de MagicBuzz.
Je croyais qu'on n'avait droit qu'à une seule clé primaire par table...

Si tu raisonne en tant que clé primaires, oui, il n'y en a qu'une. Les clés supplémentaires sont des "clé alternatives" ou "clé secondaires" (se déclarent avec SECONDARY KEY)
 
Mais le plus simple est de passer par les index uniques qui offrent la même possibilité, sans pour autant faire la différence entre les clés, puisqu'il n'y en a pas une qui a de raison d'être plus "primaire" que les autres

je pensais qu'une clé primaire était toujours unique, a quoi peut donc bien servir une cle secondaire?

j'ai déjà marqué au dessus
 
un autre exemple :
 
un table qui contient des euh... attends, je réfléchis...
 
mmmmm...
 
des ordinateurs
 
un odrinateurs à plusieurs identifiants possibles :
 
- Nom du PC sur le réseau
- IP du PC
- Adresse MAC du PC
- Utilisateur du PC (pas toujours mais bon)
- Numéro de série
- Compte d'amortissement (chaque ordinateur étant rattaché normalement à son propre compte)
 
Maintenant, on va dire que cette table permet aux administrateurs de :
-> prendre la main d'un PC alors qu'un utilisateur est en détresse, et est incapable de donner son IP. A ce moment, tu vas taper dans la clé "utilisateur".
-> faire le lien entre les utilisateurs et les logs du proxy. A ce moment, ils vont taper dans l'IP
-> faire le lien entre des logs d'un analyseur de trame et le PC qui génère des problèmes sur le réseau. A ce moment, tu tapes dans la clé "adresse mac"
-> retrouver les machines qui ont été achetées il y a plus de 3 ans (avec une table qui stocke les contrats d'achats de matériel informatique). A ce moment, tu tapes dans la clé "numero de série"
-> dans le cadre d'une étude de leasing, faire la recherche des PC dont l'amortissement est le plus faible, afin de ne pas se faire racheter les PC qui ne valent plus rien. A ce moment, tu vas taper dans la clé "compte d'amortissement"
-> faire le lien entre des erreurs reportées dans l'eventlog du serveur d'audit réseau et l'ordinateur qui les a généré : tu vas taper dans la clé "nom de l'ordinateur"
 
Tous ces champs peuvent donc servir de critère unique, donc doivent par essence :
-> être indexés
-> être uniques
ce sont donc des clé primaires
 
Maintenant, on va dire aussi que les PC sont répartis à des posts de travail, et à des étages. les postes de travail sont numérotés de 1 à x pour chaque étage, et il ne peut y avoir qu'un seul PC par poste de travail. Tu vas donc créer une nouvelle clé primaire portant sur ces deux infos. A nouveau afin de localiser rapidement quel PC est à quel poste, il te faudra indexer ces deux champs, et ils seront uniques
 
etc. etc.

ok comprends mieux maintenant