Bonjour,

Peux-tu être plus explicite, stp ... ?

;o)

polux

On a une table pige_brute où il ya les champs (campagne,support et date) tous des clés primaires c'est la table parent
et une table calendrier où il ya les champs (mois, saison) et le champs date qu'on ve extraire de la table pige_brute
donc c'est une clé étrangere n'est ce pas?
et je veux aussi qu'elle soit la clé primaire de la table calendrier car le mois et la saison ne peuvent pas l'etre
date serais une cle primaire des 2 tables calendrier et pige_brute
comment faire?????

Je ne connais pas le principe d'une table "parent" ... pour moi une base est faite de table avec des relations entre-elles de type "1,1" ou "1,n" ou "n,n". Une clé primaire ne peut être qu'unique dans une table et il ne put y en avoir qu'une et une seule ... la table pige_brute ne peut pas avoir 3 clés primaires ... il y a quelque chose qui cloche dans les relations des tables ... une clé étrangère ne peut pas devenir clé primaire de la table.

;o)

polux

Polux,

Il est vrai que sa conception des bases de données est un peu bizarre... (ou je n'ai pas tout compris!... ou c'est peut être une bonne méthode pour qu'un "kamikase" plante une base!lol)
cela dit, il a raison sur un point : Il est possible de créer 2 clés primaires dans une même table. Cela peut être utile, par ex :
Article (pk)
Version (pk)
ligne
description

La table ci-dessus considère un article unique, mais avec des variantes.

Tiens je suis etonné par ton affirmation Pollux.
Tu as bien raison sur le fait qu'une table n'a qu'une seule clé primaire.
Cependant, et tu le dis subtilement, une clé primaire peut être composé de plusieurs champs (Clé, composée de deux champs, symbolisée par (pk) dans l'exemple au dessus^^).
Donc, non sans erreur, il est habituel de penser à plusieurs clés primaires pour une table.

C'est une bonne precision de ta part, cependant pour les neophytes comme moi ce n'est pas inconcevable de penser de cette manière. Ce qui est souligner pour corriger cet conception de la clé primaire.

Amicalement

Pour repondre à la question initiale, il est donc possible d'avoir une clé primaire champ1(PK) d'une table A pointant sur la clé primaire champ1(pk) d'une table B. C'est d'ailleurs de cette maniere que l'on pourrait trouver les tables representant une généralisation en UML (pour le reverse engineering) meme si on a tendance a les regrouper en une seule table. Par contre je ne pourrais pas te dire quelle sera la reaction lors de l'enregistrement sur la table A, car un enregistrement ayant la meme clé primaire devrait aussi se trouver dans la table B. Faudrait il penser aux trigger pour lever ce problème ?