Bonsoir,
 
Je ne suis pas sur de ce que je fais d’où mon message afin de savoir si cela correspond bien à ce qu'il se fait dans une telle situation.
 
Je veux que les N° Facture soit séquentielle en fonction d'un client :
Facture (#numFacture,#idClient,...);
Dans cet exemple, (numFacture,idClient) constitue la clé primaire composé afin de résoudre cette première problématique.
 
Il y a une seconde table qui existe grâce à Facture qui est LigneFacture. Une facture peut comporter plusieurs lignes cependant je ne sais pas sur quelle colonne (de la table Facture) je dois faire pointer la clé étrangère :  
LigneFacture(#numLigneFacture,fk_Facture,...);
 
1)Dans un premier temps, sommes-nous d'accord que comme ma clé primaire est d type composé dans la table Facture, la clé étrangère dans la table LigneFacture dois également être composé ?
 
2)Une solution ne serait-ce pas de définir numFacture également comme clé secondaire et donc dans ma table LigneFacture faire pointer ma clé étrangère vers cette dernière ?
 
Merci pour vos explications

Tu peux (normalement) créer une foreign key sur plusieurs colonnes (ici sur numFacture, idClient).
 
Tu peux aussi créer une autre colonne qui serai unique sur toute ta table et utiliser ça comme foreign key, mais seulement si ton SGBD ne te permet pas de créer des foreign key sur plusieurs colonnes.

+1
Si la théorie des BD indique dans ton cas que la clé primaire doit être la "concaténation" des clés "factureID" et "clientID", en pratique, à implémenter dans les SGBD, ça pose souvent pb même pour les SGBD qui savent gérer ces cas.
En pratique, on fait souvent une clé primaire de type entier, qui va de  1 à n : c'est plus simple à utiliser et tu peux l'implémenter sur n'importe que SGBD. Après, rien ne t'empêche d'avoir un autre champ indexé de manière unique représentant ta fameuse référence de num séquentiel pour chaque client

Bonjour,
 
Merci pour vos réponses
Cependant le problème concerne également (principalement même) le fait de faire en sorte que les résultats apparaissent comme cela :  
numFacture | idClient
1                  21
2                  21
1                   5
Autrement dit numFacture doit s'incrémenter en fonction du nombre de facture que ce même client à déjà...
 
Merci.

Ben tu fais comme on a proposé :
Table Facture
IDFacture (1 à n)
NumFacture
....
IDClient (clé étrangère)
 
Table Client
IDClient (1 à n)
...
 
Et c'est l'appli (ou une procédure stockée) qui s'occupe de générer le NumFacture avec la logique métier qui va bien

Ok merci Rufo cependant n'est-ce pas mieux de prendre comme clé primaire pour la table Facture : (NumFacture,IdClient) car l'unicité qui doit être contrôler est " qu'un numéro de facture et associer à un client de manière unique  ". De plus, Dans ce cas-là IDFacture = NumFacture plus explicitement cela donne :  
 
Table Facture
IdFacture
IdClient REFERENCE Client
PRIMARY KEY(idFacture,idClient);
 
Et la suite reste valable : " Et c'est l'appli (ou une procédure stockée) qui s'occupe de générer le NumFacture avec la logique métier qui va bien ".
 
Qu'en pensez-vous ?
 
Merci

bill ? tu es de quel coin? car bien souvent un numéro de facture doit être unique dans ta compta
donc le coup d'avoir un numéro de facture / client... c'est très peu probable... ou alors c'est encore un exo, non?

mdrrr...

L'exemple de Rufo :  
idFacture(pk)  numFacture     idClient(fk)
    1                     1                     2
    2                     2                     2
    3                     3                     2
Dans ce cas-ci la clé primaire ne vérifie pas que les lignes soient uniques pour un client et numFacture. Je peux donc ajouter la ligne suivante :
    4                     1                     2 (qui est en double maintenant).
Alors qu'avec ce que j'ai écris au dessus ce problème n'est pas présent à moins que j'ai loupé quelques chose gpl73 ?

Non, bill, j'ai bien précisé que la génération du champ "numfacture" était faite par l'appli ou par une procédure stockée, l'une ou l'autre contenant la "logique métier" pour générer correctement le contenu de ce champ.
 
Et comme indiqué par gpl73, un n° de facture doit être uniquement normalement. Le fait qu'il dépende d'un client est très étrange

Ok ça marche, merci

Bonjour !
Dans mon post, je parlais de numéro de facture (la pièce comptable)... pas l'ID...
Il me semblait que tu voulais en disant :
------------------------------------------
Facture (#numFacture,#idClient,...);  
Dans cet exemple, (numFacture,idClient) constitue la clé primaire composé afin de résoudre cette première problématique
&
Cependant le problème concerne également (principalement même) le fait de faire en sorte que les résultats apparaissent comme cela :  
numFacture | idClient  
1                  21  
2                  21  
1                   5  
Autrement dit numFacture doit s'incrémenter en fonction du nombre de facture que ce même client à déjà
---------------------------------------------------------------------------
 
tu as bien la possibilité d'avoir : un meme numéro de facture dans ta comptabilité:
Select idclient from matablefacture where numfacture = 1 => 2 lignes 21, 5
 
et ça c'est pas très,très "légale" (du moins en France)...
 
le fait de claquer des ID ou pas n'est pas la question...  
la vrai question c'est est ce que tu dois avoir un numéro de facture uniquement incrémentatal et continu (pour toute ta compta).
 
ID, Numfact, idClient
1         1           1
2         2           3
3         3           3
4         4           1
5         5           2
6         6           2
 
 
 
ou par client...
 
 
et là tu peux avoir, comme le dit rufo :
 
ID, Numfact, idClient
1         1           1
2         1           2
3         1           3
4         2           1
5         2           2
6         2           3
 
Guillaume

Bonjour gpl73,
 
Merci pour ces informations complémentaires ça confirme que j'ai bien compris en fin de course
 
Bonne journée.