[SQL] clef étrangère
Résolu/Fermé
okuni
Messages postés
1221
Date d'inscription
jeudi 4 septembre 2008
Statut
Membre
Dernière intervention
2 janvier 2014
-
3 janv. 2010 à 11:35
okuni Messages postés 1221 Date d'inscription jeudi 4 septembre 2008 Statut Membre Dernière intervention 2 janvier 2014 - 7 janv. 2010 à 15:28
okuni Messages postés 1221 Date d'inscription jeudi 4 septembre 2008 Statut Membre Dernière intervention 2 janvier 2014 - 7 janv. 2010 à 15:28
A voir également:
- [SQL] clef étrangère
- Clef usb non reconnue - Guide
- Formater clef usb - Guide
- Note clef de fa - Télécharger - Création musicale
- Logiciel sql - Télécharger - Bases de données
- Clef usb bootable - Guide
22 réponses
Smoking bird
Messages postés
870
Date d'inscription
mardi 11 mars 2008
Statut
Membre
Dernière intervention
10 juillet 2011
58
7 janv. 2010 à 14:02
7 janv. 2010 à 14:02
Comme je t'ai dit: j'ai veillé à la cohérence et à la clareté de ta structure, grâce aux exemples que tu m'as donné. Faut vraiment veiller à ce qu'un champ porte un nom qui représente exactement sa signification: un champ réservé à l'id d'une série doit s'appeller id_serie ou idSerie ou serie_id mais pas moins clair :D. Juste 'serie' c'est pas possible.
Du coup, n'importe qui comprend aisément les rapports logiques faits entre plusieurs tables (ex: 'Tiens, je comprends que l'id d'une série apparait sur cette table à cette emplacement et sur cette autre table à cet autre emplacement'). C'est idéal pour bien travailler, les choses doivent être le plus simple et le plus clair possible. Ceci fait, il faut vérifier que des champs aux noms et aux significations identiques possèdent également des types identiques, sinon ça foire. Un champ id_serie type varchar(10) sur une table ne correspond pas à un champ id_serie type int ou varchar(25) sur une autre table, par exemple, et donc les utiliser pour monter une clef étrangère est impossible.
L'étape suivante, c'est de t'assurer que des index sont posés sur les champs qui composent ta clef étrangère. Théoriquement, sur la table parent la clef primaire n'a pas besoin de se voir ajouter un index, puisque c'en est déjà un (si, bien entendu, la clef primaire fera partie de la clef étrangère^^). Donc tu vas sur la table enfant de la relation, tu cherches le champ qui complète la clef étrangère et tu le mets en index.
Et normalement, c'est à ce moment que tu peux placer ta clef étrangère, si tout se passe bien^^.
Du coup, n'importe qui comprend aisément les rapports logiques faits entre plusieurs tables (ex: 'Tiens, je comprends que l'id d'une série apparait sur cette table à cette emplacement et sur cette autre table à cet autre emplacement'). C'est idéal pour bien travailler, les choses doivent être le plus simple et le plus clair possible. Ceci fait, il faut vérifier que des champs aux noms et aux significations identiques possèdent également des types identiques, sinon ça foire. Un champ id_serie type varchar(10) sur une table ne correspond pas à un champ id_serie type int ou varchar(25) sur une autre table, par exemple, et donc les utiliser pour monter une clef étrangère est impossible.
L'étape suivante, c'est de t'assurer que des index sont posés sur les champs qui composent ta clef étrangère. Théoriquement, sur la table parent la clef primaire n'a pas besoin de se voir ajouter un index, puisque c'en est déjà un (si, bien entendu, la clef primaire fera partie de la clef étrangère^^). Donc tu vas sur la table enfant de la relation, tu cherches le champ qui complète la clef étrangère et tu le mets en index.
Et normalement, c'est à ce moment que tu peux placer ta clef étrangère, si tout se passe bien^^.
okuni
Messages postés
1221
Date d'inscription
jeudi 4 septembre 2008
Statut
Membre
Dernière intervention
2 janvier 2014
126
7 janv. 2010 à 15:28
7 janv. 2010 à 15:28
Ok merci beaucoup pour ton aide :)