Discussion :

[niko9600]

Bonjour,

Merci Ph_Gr pour ton intervention, mais en fait tu ne me contredis pas, au contraire tu confirme ce que j'ai dit....

Comme l'indique l'aide que tu as intégré dans ta réponse, on ne peut utiliser directement une clé composée dans une requête SQL ! c'est exactement ce que je dis !
On est obligé d'utiliser les composantes de la clé, et comme je l'ai dis ma clé est étrangère (donc c'est la clé liée à la vrai clé composée dans un autre fichier), donc je n'ai pas les composantes de la clé. D'où la discussion que nous avions avec Jean-PhI, sur le fait que les clé composée ont quelques lacunes, notamment le fait qu'on ne puisse récupérer les composantes sur une clé étrangère....

donc pas de requête SQL malheuresement (ou alors je peux bien entendu faire un hlirecherchepremier sur la table d'origine, récupérer la valeur des composantes de chaque clé, mais de toute façon la table dans laquelle je cherche n'a QUE la clé composée, et non les composantes donc je n'ai pas le choix..)

Je vois que personne ne comprend le montage, donc je l'explicite un peu plus précisément :

Mon fichier EXAM_PROG (qui lie les fichiers EXAM et PROG (fichier créé car liaison n-n)) possède une clé primaire nommé ID, qui est une clé composée des 2 ID(auto) de EXAM et PROG.
Le fichier EEQ est relié au fichier EXAM_PROG par l'intermédiaire de cette clé, qui se nomme IDEXAM_PROG dans le fichier EEQ. Dans le fichier EEQ sur lequel je fais mon Hfiltre, je n'ai pas les composantes de la clé (IDEXAM et IDPROG). Donc je ne peux utiliser de SQL ou les filtres de POUR TOUT (j'avais déjà testé bien entendu) ! Le seul moyen (à ma connaissance) c'est Hfiltre.

Est-ce plus clair à présent ?

[DelphiManiac]

...Comme l'indique l'aide que tu as intégré dans ta réponse, on ne peut utiliser directement une clé composée dans une requête SQL ! c'est exactement ce que je dis !
On est obligé d'utiliser les composantes de la clé, et comme je l'ai dis ma clé est étrangère (donc c'est la clé liée à la vrai clé composée dans un autre fichier), donc je n'ai pas les composantes de la clé. D'où la discussion que nous avions avec Jean-PhI, sur le fait que les clé composée ont quelques lacunes, notamment le fait qu'on ne puisse récupérer les composantes sur une clé étrangère....

Je ne comprend pas bien cette remarque !!

Si dans la table EEQ tu n'as pas les valeurs de ta clé composée, tu créé dans ta requête une liaison vers la table EXAM_PROG qui elle contient les valeurs et tu poses ton where sur les rubriques de la table EXAM_PROG.

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
SELECT     EEQ.NomEEQ AS NomEEQ
FROM 
    EXAM_PROG,    
    EEQ
WHERE 
    EXAM_PROG.IDEXAM_PROG = EEQ.IDEXAMIDPROG
    AND
    (
        EXAM_PROG.IDPROG = 1
        AND    EXAM_PROG.IDEXAM = 1
    )

Par contre, je ne comprend pas comment tu fais pour avoir une clé composé dans la table EEQ qui reprend les valeurs IDEXAM et IDPROG sans que ces valeurs apparaissent dans la table EEQ sous forme de rubrique. Une clé composé n'est qu'un index composé de plusieurs rubriques apparaissant dans ton fichier, ou alors ce n'est peut être pas une clé composé. Dans les 2 cas, la solution proposé au dessus te permet de filtrer tes enregistrements.

Si la réponse ne convient pas ou te semble erroné, essaye de faire un projet de test en synthétisant au maximum ton analyse et poste ici ton analyse de test en pièce jointes. Cela nous permettra de mieux comprendre la question, vu qu'apparemment ce n'est clair pour personne

[Invité]

Ah oui, ça y est, j'ai compris, et franchement, je ne pensais pas que windev pouvait être aussi crade que ça! C'est incroyable!
En recréant les tables sous mon éditeur d'analyse avec les indications de niko, j'ai effectivement pu reproduire le cas : au moment de la création de la table EEQ, quand j'ai mis tout ça en place, il m'a proposé la création de la clé "IDPROG_EXAM" dans la table "EEQ"... En binaire! ça alors!

Bon, OK je comprend mieux.

En revanche, quand j'ai testé la création d'une requête avec ça, il s'est trouvé que j'ai pu référencer la clé "IDPROG_EXAM" de "PROG_EXAM" qui, pour le coup, est bien reconnue par l'éditeur de requête!

Donc, la solution de Delphi est OK!

[DelphiManiac]

Autant je trouve Windev "crade" sur pas mal de point, autant sur ce point là, il n'y a rien qui sorte du standard ^^ si ce n'est la jointure de la requête exprimé par défaut avec une expression d'égalité dans le where plutôt qu'un join.

Content que cela fonctionne.

[Invité]

En fait, ce que je ne trouve pas terrible dans ce cas c'est l'histoire de la "clé binaire" qui est mise au lieu d'une vrai clé composée comme cela se fait dans tous les autres SGBD. Alors je comprend tout à fait que Niko ait été déconcerté par cela...

[niko9600]

DelphiManiac à écrit :
Je ne comprend pas bien cette remarque !!

Si dans la table EEQ tu n'as pas les valeurs de ta clé composée, tu créé dans ta requête une liaison vers la table EXAM_PROG qui elle contient les valeurs et tu poses ton where sur les rubriques de la table EXAM_PROG.

Tout à fait je peux faire cela, mais du coup je ne vois plus l'interêt de la clé composée, si à chaque fois on dois se faire des requête avec jointure pour remonter à la table originale ... du coup mon Hfiltre + POUR TOUT (ou Hlitpremier..) est vraiment plus simple.

Par contre, je ne comprend pas comment tu fais pour avoir une clé composé dans la table EEQ qui reprend les valeurs IDEXAM et IDPROG sans que ces valeurs apparaissent dans la table EEQ sous forme de rubrique. Une clé composé n'est qu'un index composé de plusieurs rubriques apparaissant dans ton fichier, ou alors ce n'est peut être pas une clé composé. Dans les 2 cas, la solution proposé au dessus te permet de filtrer tes enregistrements.

Comme la dit Ph_Gr windev créé un clé binaire, donc tu ne peux l'interpréter. Je n'ai pas les rubriques IDEXAM et IDPROG dans EEQ car c'est le fichier lié à EXAM_PROG ! Dans EXAM_PROG j'ai bien les rubriques IDEXAM et IDPROG, et je dis à windev ; "créé un clé composée à partir de ces 2 rubriques, qui se nomme ID : c'est la clé primaire de EXAM_PROG".
Ensuite je créé le fichier EEQ, qui est lié au fichier EXAM_PROG par cette clé. Donc la clé étrangère correspondante crée dans EEQ se nomme IDEXAM_PROG, et c'est une clé binaire !! (ce qu'explique Ph_Gr). Donc tu ne peux accéder aux composantes directement, il faut faire une requête tel que tu l'a écris, ou encore un HLitrecherche.
C'est ça que nous critiquons ! et qui sort du standard puisque c'est le seul SGBD à ma connaissance à procéder de la sorte.

[Invité]

Néanmoins, ton problème est quand même résolu par cette requête...

Vu tout ce que j'ai déjà découvert de bizarre avec windev, finalement cette nouvelle bizarrerie est dans la suite logique!

[DelphiManiac]

Néanmoins, ton problème est quand même résolu par cette requête...

Vu tout ce que j'ai déjà découvert de bizarre avec windev, finalement cette nouvelle bizarrerie est dans la suite logique!

Personnellement, ce que je trouve bizarre c'est de réaliser un lien entre 2 tables sur une clé composé, mais c'étais dans l'énoncé du problème et n'ai pas voulu parler de ce point auparavant. Je ne vois aucun rapport entre Windev et le problème posé, le problème étant le même quelque soit la base de données utilisée. Quelque part, dans le schéma présenté, il y a duplication de l'information, c'est comme si pour filtrer sur le nom de l'exam, on dupliquait le nom de l'exam dans la table EEQ. Ici le symptôme est le même, pour filtrer sur un IDExam, on duplique IDExam dans la table EEQ. Ce n'est pas une façon "correcte" de faire.

Pour ma part, je n'aurais pas fait comme cela, j'utilise toujours en clé primaire un ID Auto, même sur une table de relation n-n, et lorsque j'ai besoin de filtrer sur une valeur quelconque de mes tables, je rétablie lors de la requête les relations nécessaires pour réaliser le filtre.

Actuellement, on a une relation indirecte entre 3 tables : IDExam de la table Exam (clé primaire), IDExam de la table EXAM_PROG, clé externe et IDExam de la table EEQ (clé ?????).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Table Exam :
  IDExam, clé auto
Table Prog:
  IDProg, clé auto
Table ExamProg :
  IDExamProg, clé auto
  IDExam relié à la table Exam
  IDProg relié à la table Prog
EEQ :
  IDEeq : clé auto
  IDExamProg, relié à la talbe IDExamProg

Toutes mes clés étant du coup des ID auto incrémentés. C'est une façon de faire qui rend les relations entres les tables complètement indépendantes de l'information que transporte la table. Bien sûr les clefs auto incrémentés n’apparaissent jamais à l'utilisateur.

Une autre solution qui serait envisageable, si l'on a bien une relation de 1-1 entre la table EXAM_PROG et la table EEQ, serait de supprimer la table EEQ et de remonter les champs de la table EEQ dans la table EXAM_PROG. Cette solution serait bien plus propre. Une table de relation n'a pas pour obligation d'être uniquement le conteneur des 2 clés, on peut tout à fait stocker dans cette table de relation toutes informations complémentaires qualifiant cette relation.

Concernant ta remarque

Donc la clé étrangère correspondante crée dans EEQ se nomme IDEXAM_PROG, et c'est une clé binaire !! (ce qu'explique Ph_Gr).

Si tu tiens à tout prix à dupliquer l'information dans EEQ, ce n'est pas parce que l'assistant de Windev te propose de créé une clé binaire qu'il faut que tu t'y tienne, tu peux tout à fait créé toi même dans EEQ, la rubrique IDExam, la rubrique IDProg, la clé composé IDExamProg que tu forces en clé unique et ensuite établir la relation avec EXAM_PROG sur cette clé composé que tu as créé.

[niko9600]

Personnellement, ce que je trouve bizarre c'est de réaliser un lien entre 2 tables sur une clé composé, mais c'étais dans l'énoncé du problème et n'ai pas voulu parler de ce point auparavant. Je ne vois aucun rapport entre Windev et le problème posé, le problème étant le même quelque soit la base de données utilisée. Quelque part, dans le schéma présenté, il y a duplication de l'information, c'est comme si pour filtrer sur le nom de l'exam, on dupliquait le nom de l'exam dans la table EEQ. Ici le symptôme est le même, pour filtrer sur un IDExam, on duplique IDExam dans la table EEQ. Ce n'est pas une façon "correcte" de faire.

Pour ma part, je n'aurais pas fait comme cela, j'utilise toujours en clé primaire un ID Auto, même sur une table de relation n-n, et lorsque j'ai besoin de filtrer sur une valeur quelconque de mes tables, je rétablie lors de la requête les relations nécessaires pour réaliser le filtre.

Actuellement, on a une relation indirecte entre 3 tables : IDExam de la table Exam (clé primaire), IDExam de la table EXAM_PROG, clé externe et IDExam de la table EEQ (clé ?????).

ci joint une partie de l'analyse car je vois que le montage n'est toujours pas compris


Oui il y a duplication de certaines données dans EXAM_PROG et EEQ volontairement. En effet les données de EXAM_PROG sont les données "en cours" pour l'EXAM et le PROG. Dans EEQ ce sont les données sauvegardées au moment de la saisie, qui peuvent être différentes car elles évoluent dans le temps, et on doit garder la trace dans EEQ. Les données dupliquées dans EXAM_PROG sont uniquement les données en cours et sont susceptibles de changer à chaque nouvelle saisie d'un EEQ.
Donc je ne peux pas supprimer EEQ c'est la donnée finale, le fichier principal.

Comme tu le vois il n'y a pas d'IDEXAM dans EEQ, car ce qui m’intéresse c'est le couple EXAM_PROG. Un EXAM peut avoir plusieurs PROG, et inversement, et ce sont les autres rubriques de EXAM_PROG qui vont paramétrer cette liaison. Donc dans EEQ je référe directement à la table EXAM_PROG pour récupérer ces rubriques. (qui contiennent les valeurs par défaut pour les même rubriques de EEQ).

Si tu tiens à tout prix à dupliquer l'information dans EEQ, ce n'est pas parce que l'assistant de Windev te propose de créé une clé binaire qu'il faut que tu t'y tienne, tu peux tout à fait créé toi même dans EEQ, la rubrique IDExam, la rubrique IDProg, la clé composé IDExamProg que tu forces en clé unique et ensuite établir la relation avec EXAM_PROG sur cette clé composé que tu as créé.

Oui bien sur je peux créé des "fausses" clés composées, mais je cherche d'abord à utiliser les fonctions par défaut de windev, afin de bien comprendre le fonctionnement (je débute en windev). Et après tout mon code fonctionne, c'est juste que je dois remettre le Hfiltre avant le 2e POUR TOUT, ou alors je fait la requête citée plus haut.

[DelphiManiac]

Comme tu le vois il n'y a pas d'IDEXAM dans EEQ

Et bien si, il y a bien un IDExam dans la table EEQ, ce n'est pas parce que cette information est masqué dans une clé binaire qu'elle n'existe pas et qu'elle ne représente pas l'IDExam.

Quand je parle d'information dupliqué, je parle principalement des valeurs de IDExam et de IDProg qui apparaissent dans les tables EXAM_PROG et EEQ. Ton IDEXAM_PROG de la table EEQ n'est qu'une représentation des valeurs IDExam et IDProg (sous forme de clé binaire si j'ai bien compris actuellement). Quelque part je trouve dérangeant de dupliquer cette information.

Soit IDExam et IDProg peuvent évoluer séparément dans le temps entre les tables EXAM_PROG et EEQ (ce qui signifie que tu n'as donc pas de lien réel entre les table EXAM_PROG ET EEQ) et dans ces cas, autant stocker en clair dans la table EEQ les 2 ID (IDExam et IDProg) quitte a déclarer une clé composé après coup sur ces 2 champs (mais cette clé composé n'est nécessaire que pour optimiser des recherches)

Soit ces 2 valeurs ne peuvent évoluées séparément (tu as bien une relation entre EXAM_PROG et EEQ) et dans ce cas je ne vois pas l’intérêt de stocker IDExam et IDProg dans la table EEQ (quelque soit la forme que prend ce stockage), il suffit de définir une clé étrangère IDEXAM_PROG dans la table EEQ et d'utiliser cette clé pour établir la relation sur la clé primaire ID de EXAM_PROG. On peut ainsi supprimer la clé composé IDEXAM_PROG de la table EEQ.

Pour faire un filtre sur un IDexam ou un IDProg, tu parcours d'abord la table parente, dans ce cas EXAM_PROG pour isoler tout les enregistrements correspondant à ton filtre et ensuite, pour chaque enregistrement de la table EXAM_PROG, tu lis l'enregistrement correspondant de la table EEQ.

Essaye de voir cela globalement, si tu voulais filtrer tout les enregistrements de EEQ dont le nom de l'exam contient 'Test', dupliquerais tu le nom de l'exam dans la table EEQ ?


Par principe, on ne duplique jamais une information dans une base de données, les rares cas où cela se produit, c'est quand on rencontre des problèmes de performance et que dans ces cas, on tolère le fait que la base de données soit dénormalisée.

Article sur les règles de normalisation des bases de données : http://fr.wikipedia.org/wiki/Forme_n...elationnelles)

[niko9600]

Soit ces 2 valeurs ne peuvent évoluées séparément (tu as bien une relation entre EXAM_PROG et EEQ) et dans ce cas je ne vois pas l’intérêt de stocker IDExam et IDProg dans la table EEQ (quelque soit la forme que prend ce stockage), il suffit de définir une clé étrangère IDEXAM_PROG dans la table EEQ et d'utiliser cette clé pour établir la relation sur la clé primaire ID de EXAM_PROG. On peut ainsi supprimer la clé composé IDEXAM_PROG de la table EEQ.

Mais je ne stock/duplique rien du tout, c'est une clé étrangère ! essaye de reproduire mon analyse (juste le lien entre EXAM_PROG et EEQ) et tu verra que tu ne peux faire autrement. Etant donné que ma clé primaire ID de EXAM_PROG, c'est la clé composée !
c'est clair sur l'analyse on voit bien les 2 clé avec une flèche au niveau de l'ID de EXAM_PROG. Donc quand je créé la liaison entre EXAM_PROG et EEQ, windev me créé un rubrique (la clé étrangère) que j'ai appelé IDEXAM_PROG, exactement comme tu dis de faire. Sauf que vu que la clé primaire est composée(donc binaire) la clé étrangère sera binaire aussi. Ce que tu dis de faire c'est exactement ce que j'ai fait.

J'ai l'impression que tu crois que la clé composée est créé dans EEQ mais pas du tout, dans EEQ c'est juste la clé étrangère. Après j'aurais peut-être pu créer une clé primaire ID auto dans EXAM_PROG plutôt que d'utiliser la clé composé à cet effet, mais je ne pensais pas avoir de soucis avec les clé composées, et voulais tester justement le fonctionnement dans les liaisons notamment.

De plus je pensais pouvoir récupérer les composantes de la clé étrangère, mais ce n'est pas possible donc c'est vrai que du coup cela perd de son interêt. Même si ma politique est de créer le moins de rubriques et champs possible, il serait peut-être préférable dans ce cas de ne pas utiliser la clé composée en clé primaire, pour simplifier les filtres et les liaisons par la suite...


Je pense que ce que tu as du mal à comprendre, c'est la façon dont windev gère les clé composées, et là tu rejoins la discussion que nous avions avec Ph_Gr../

[DelphiManiac]

...Je pense que ce que tu as du mal à comprendre, c'est la façon dont windev gère les clé composées, et là tu rejoins la discussion que nous avions avec Ph_Gr../

J'ai sûrement du mal à comprendre. Windev n'impose, à ma connaissance, aucune obligation quand à la relation entre les tables et quand au type des champs intervenant dans cette relation.

En pièce attachés, se trouve 2 projets, ce sera sûrement plus parlant que de faire un long laïus ici. Le projet Test0001 reste dans l'esprit de ce que tu as choisi, c'est à dire que la relation entre la table Exam_Prog et EEQ est basé sur une clé composé, le projet Test0002 reste dans l'esprit de la solution que j'aurais choisi par défaut, c'est à dire une relation simple de 1-n (ou 1-1) entre Exam_Prog et EEQ basé sur un ID auto.

Je n'assure nullement qu'une solution est meilleure que l'autre. Par contre, dans la solution 1, je n'utilise pas de clé binaire ce qui a l'avantage d'avoir les valeurs composantes de la clé au niveau de EEQ, et le fait de ne pas utiliser une clé binaire n'est pas plus coûteux en terme de ressource. Dans ton cas on a une clé binaire qui fait 8 octets de long et qui correspond à IDExam et IDProg et un index sur cette clé binaire, dans mon cas on a 2 champs de 4 octets de long (IDExam et IDProg) et un index composé de ces 2 champs.

[niko9600]

donc en fait clairement ce que tu dis c'est qu'il ne faut pas utiliser une clé composée en clé primaire c'est ça ? et même de ne pas en utiliser du tout d'ailleurs puisque dans TEST2 qui est celui que tu aurais fait par défaut il n'y a pas de clé composée du tout. C'est sûr que du coup plus de problèmes de filtres mais ce n'est pas ce que j'avais compris de tes messages...
Comme je l'ai déjà dit j'avais créé une clé composée à la base car je pensais pouvoir récupérer les composantes à partir de la clé étrangère sans être obligée de faire la requête (que tu dois faire avec ton montage).

[DelphiManiac]

donc en fait clairement ce que tu dis c'est qu'il ne faut pas utiliser une clé composée en clé primaire c'est ça ? et même de ne pas en utiliser du tout d'ailleurs puisque dans TEST2 qui est celui que tu aurais fait par défaut il n'y a pas de clé composée du tout. C'est sûr que du coup plus de problèmes de filtres mais ce n'est pas ce que j'avais compris de tes messages...
Comme je l'ai déjà dit j'avais créé une clé composée à la base car je pensais pouvoir récupérer les composantes à partir de la clé étrangère sans être obligée de faire la requête (que tu dois faire avec ton montage).

La solution Test0001 utilise des clés composés dans l'esprit de ce que tu avais mis en place au départ, mais par contre elle n'utilise pas de clés binaires, du coup la requête de la solution 1 a accès directement au ID de la clé composée.

Par contre, il est vrai que, personnellement, je privilégie la solution 2. Ne serait-ce que parce que je ne trouve pas logique de dupliquer les IDExam et IDPRog (qui sont des clés externes de 2ième niveau) dans la table EEQ, je préfère avoir un IDAuto sur la table EXAM_PROG et utiliser cet ID pour établir la relation avec EEQ. Ainsi chaque table à une vocation bien défini.
- La table Exam décrit un examen
- La table Prog décrit un programme
- La table ExamProg établi la relation entre un examen et un programme et cette relation est uniquement établi dans cette table.
- La table EEQ historise les paramètres lié à un couple exam/prog au un instant T et se sert pour cela de la table ExamProg qui est dédié a établir cette relation.

Mais si tu es plus a l'aise avec les clés composés ou que tu trouves cela plus naturel, la solution 1 fonctionne et à l'avantage de ne pas passer par des clés binaires qui restent obscures quand à leur contenu.

donc en fait clairement ce que tu dis c'est qu'il ne faut pas utiliser une clé composée en clé primaire c'est ça ?

Oui pour moi une clé composé n'est nécessaire que pour optimiser des plans de requêtes.

---

Comme quoi un exemple vaut mieux que plusieurs longs discours pour faire passer une idée

[niko9600]

En effet dans ta solution 1 tu n'utilise pas de clé binaire, mais du coup tu dois tout dupliquer donc en effet c'est pas terrible. Et en tout cas ce n'est pas du tout dans cet esprit que j'ai fait mon analyse.
J'ai bien compris le principe de ne pas utiliser de clé composée en clé primaire, notamment à cause de ces problèmes de clé étrangères et de filtres. C'était pour tester et je ne le referai pas.

On m'a également proposé une solution avec une seule boucle sur le forum PCSOFT si vous voulez voir il y a le code complet à la fin. (même titre de discussion).

Merci pour votre aide.

[DelphiManiac]

En effet dans ta solution 1 tu n'utilise pas de clé binaire, mais du coup tu dois tout dupliquer donc en effet c'est pas terrible...

Je ne sais plus comment le dire (où alors c'est vraiment moi qui ne comprend plus rien, ce qui est fortement envisageable :p).

Peut être que tu te mélanges les pinceaux entre les rubriques et les index. Les rubriques sont stockées physiquement dans le fichier .FIC et les index dans le fichier .NDX.

Concernant EEQ :

Dans ta solution, tu as, 1 rubrique binaire de 8 octets stockée dans le .FIC et un index (de 8 octets aussi) sur cette rubrique stocké dans le .NDX
Dans ma solution 1, tu as 2 rubriques de 4 octets chacune (2x4=8) stockées dans le fichier .FIC et un index de type clé composé (de 8 octets) stocké lui dans le .NDX et pas dans le .FIC. La clé composé n'est pas une rubrique, c'est juste un index.

Ce n'est pas parce que l'on voit apparaître une clé composé comme une rubrique dans la liste des rubriques d'une table Windev que cela en fait une rubrique. Visuellement ma solution donne l'impression de comporter une rubrique de plus (la clé composé), mais ce n'est pas une rubrique.

En terme de duplication les solutions sont équivalentes, c'est pour ça que je m'évertue depuis le début à parler d'information dupliqué.

Ci joint 2 copies d'écran. Dans les 2 cas l'enregistrement fait 17 octets de long (9 octets fixe pour tout enregistrement en Windev + 8 octets de données).

[niko9600]

En effet je n'avais pas saisi que la clé composée n'était qu'un index.
donc ce que tu voulais dire, c'est que quand je fait la liaison de EXAM_PROG vers EEQ, et qu'il me créé une clé étrangère binaire dans EEQ (IDEXAM_PROG), en fait il créé uniquement une rubrique binaire et un index ? c'est pour ça que tu parlais de duplication (étant donné que IDEXAM et IDPROG se retrouve dans la rubrique binaire ?
parce que c'était pas clair du tout à ce niveau dans tes message :d

Et donc ce qui te gêne c'est que la liaison est faite sur 2 rubriques, alors qu'elle pourrait-être fait sur une seule (ID auto) ?

PS : concrètement une liaison est entre 2 rubriques ou entre les 2 index de ces rubriques ?

[DelphiManiac]

En effet je n'avais pas saisi que la clé composée n'était qu'un index.
donc ce que tu voulais dire, c'est que quand je fait la liaison de EXAM_PROG vers EEQ, et qu'il me créé une clé étrangère binaire dans EEQ (IDEXAM_PROG), en fait il créé uniquement une rubrique binaire et un index ? c'est pour ça que tu parlais de duplication (étant donné que IDEXAM et IDPROG se retrouve dans la rubrique binaire ?
parce que c'était pas clair du tout à ce niveau dans tes message :d

C'est tout à fait cça, désolé de ne pas avoir été clair :p

Et donc ce qui te gêne c'est que la liaison est faite sur 2 rubriques, alors qu'elle pourrait-être fait sur une seule (ID auto) ?

Oui, je préfère n'avoir qu'a un seul endroit la qualification de la liaison, ce qui me permets de modifier la liaison (par exemple) sans avoir à répercuter cette modification sur l'ensemble des relations. Exemple : dans ton cas, tu pourrais être amener à modifier l'IDExam d'une liaison (table EXAM_PROG), si la table EEQ utilise la même clé composé, il faut répercuter la modification sur la liaison avec la table EEQ, si l'on utilise un ID Auto pour la relation EXAM_PROG -> EEQ, il n'y a pas d'incidence.

PS : concrètement une liaison est entre 2 rubriques ou entre les 2 index de ces rubriques ?

Une liaison est entre 2 rubriques, les index ne sont là que pour améliorer les temps d'accès et facilité la vérification d'unicité.

[niko9600]

Oui, je préfère n'avoir qu'a un seul endroit la qualification de la liaison, ce qui me permets de modifier la liaison (par exemple) sans avoir à répercuter cette modification sur l'ensemble des relations. Exemple : dans ton cas, tu pourrais être amener à modifier l'IDExam d'une liaison (table EXAM_PROG), si la table EEQ utilise la même clé composé, il faut répercuter la modification sur la liaison avec la table EEQ, si l'on utilise un ID Auto pour la relation EXAM_PROG -> EEQ, il n'y a pas d'incidence.

En fait j'ai mis des règles d'intégrité pour éviter ce genre de problème. Je ne peux modifier une IDEXAM ou PROG si l'IDEXAM_PROG équivalent existe dans EEQ.
Je viens de retester du coup et le mécanisme HFSQl se déclenche bien. Après il y a peut-être des application ou on peut changer les ID mais perso j'évite. Je préfère re créé un nouvel ID si besoin, et ce car je dois également avoir une bonne traçabilité dans mon appli.

Néanmoins par la suite je ferai également avec des ID(auto), car tu as raison sur le principe c'est mieux