bjr
 
J'aimerai juste avoir confirmation :
 
Une table A possède une clef primaire composé de 2 champs (couple).
 
Elle est reliée a une autre table B par une relation type CIF.
 
Le couple cle de A va donc constituer une clef etrangere de B (au niveau du MPD).
 
Dans access je crois que cela n'est pas possible. Access n'accepte qu'un champ unique en clef etrangere provenant de la table A. Il faut donc passer par un identifiant relatif (type auto inc) est ce que c'est vrai ou pas ??    
 
thx

oui, access autorise les clefs etrangeres que si ta clef est un champ unique et non plusieurs champs.
 
 
en revanche, comme tu le dis, tu peux créer une clef unique sur le champ que tu veux, et le mettre en reference simple, de sorte a ce que tous les elements que tu inseres soient forcément dans l'autre table

Conceptuellement parlant, c'est pas très propre, mais tu peux tout à fait te passer de clé étrangère. D'autant plus que le utilité se résume à faire ramer la base plusqu'autrechose : in est rare qu'on insère comme un sagouin des id qui n'existent pas dans la table mère (on fait les vérifs avant) et on ne fait jamais de delete cascade constraints (c'est d'ailleurs désactivé dans la plupart des SGBD)

donc selon toi il est plus rapide de faire ses verifications soi meme, que le SGBD verifie lui meme si l'id que tu inseres est egalement present ds la table mere ?

merci de vos reponses
 
Yep un controle a la main remplace facilement les fk. Dans mysql, il a qqu versions de cela , il ne gerait pas les clef etrangere et tu devait faire le controle a la main , c pas la mort (je crois que mysql gere les foreign now)
 
a+

Oui, ca toi tu les fait quand tu en as besoin, alors que le SGBD va les faire systématiquement, y compris dans des cas où il est impossible qu'il y ait le moindre problème de cohérence.
 
Pour être plus précis même, sur les grosses bases, sont rigoureusement interdits :
- Triggers
- Clé étrangères
- Clé primaires (remplacées par une série d'index uniques, bien plus rapides pour les vérifications) - dorénavant, "primary key" n'est d'ailleurs plus qu'un alias de création d'index unique

pour les triggers je suis d'accord ...
 
mais pour les clés etrangeres, ca me parait normal qu'une verification systematique se fasse ... c'est un devoir d'etre certain de la cohérence de ta base

Sauf que dans 99.99% des cas, dans une base complexe, tes clé étrangères sont plus complexes qu'une simple relation bête entre deux tables, mais doivent s'assurer de la cohérence d'un certain nombre de paramètres.
 
Par exemple :
 
-> Une table "personne".
 
Tu peux modéliser un arbre généalogique en ajoutant deux champs "père" et "mère", pointant sur sur les id de "personne".
 
Seulement, une mère est forcément féminine, un père est forcément masculin. Deplus, la mère doit être vivante au moment de l'enfantement, le père doit être vivant au moins neuf mois avant l'enfantement, les parents doivent avoir au moins 14 ans de plus que l'enfant, etc. etc.
 
Bon, ben je te souhaite du courage pour gérer cette clé étrangère autrement qu'au niveau soft.
 
La gestion des clés dans une gestion de stocks par exemple est TRES LARGEMENT aussi compliquée. Il est donc ridicule de gérer les contraintes d'intégrité au nivea de la base pour les quelques tables minables qui restent, puisque la PREMIERE règle pour faire un développement propre et portable, c'est de regrouper toutes les fonctions de même niveau au même endroit : soit tout dans la base, soit rien dans la base. Mais pas p'tête ben que oui p'tête ben que non, avec le risque de valider plusieurs fois de suite les mêmes données, avec tout les risques que cela implique, par exemple qu'une vérification à un niveau invalide une vérification faite à un autre niveau, qu'on passe alors des mois à traquer pour corriger le bug.
 
Donc les clé étrangères, comme 80% d'un modèle de données, c'est pour faire joli dans le cahier des charges.
 
PS: c'est pas parceque c'est pour faire joli que ce n'est pas nécessaire. Il est vital d'avoir fait en amont une passe en MERISE pour débroussailler le terrain et comprendre comment le problème peut se résoudre. Mais très vite lors de la phase de conception, on abandonne tous les grands principes de MERISE qui ne sont pas adaptés à la vie réelle, au profit de traîtements moins jolis mais plus réalistes, et au final souvent plus propre malgré les apparences.