2 champs comme clé primaire ?

Version imprimable

01/04/2010, 22h11
guipe

2 champs comme clé primaire ?

Bonjour, je m'explique j'ai 3 tables:

joueur_licencie(numero_licence,nom_joueur,prenom_joueur,adresse_joueur,ville_joueur,nom_club,elo,classement_championnat)

et

club(nom_club,ville_club,adresse_club,pageweb_club,nom_ligue)

et

ligue_regionale(nom_ligue,pageweb_ligue).

Je veux ajouter une contrainte pour qu'il ne soit pas possible qu'un joueur puisse être inscrit dans deux clubs différents.Comment faire ?
J'ai pensé à mettre 2 champs(numero_licence et nom_club ) en tant que clé primaire dans ma table joueur_licencie.

A votre avis quelle est la bonne méthode ?
Merci !
01/04/2010, 22h17
asdf007

Citation:

Envoyé par guipe

Je veux ajouter une contrainte pour qu'il ne soit pas possible qu'un joueur puisse être inscrit dans deux clubs différents.

Je vois pas comment c'est possible avec ton schéma actuel. Un licencié n'a qu'un club (nom_club).
01/04/2010, 22h19
Mr N.

Ne rien faire.

Vu ta définition de joueur_licencie, il n'est pas possible d'avoir plusieurs clubs pour un joueur.
01/04/2010, 23h07
guipe

D'accord et une dernière question :

joueur_licencie(numero_licence,nom_joueur,prenom_joueur,adresse_joueur,ville_joueur,nom_club,elo,classement_championnat)

Ma clé primaire doit obligatoirement être définie en AUTO INCREMENT?

Dans quels cas doit-on le faire ?

Merci !
02/04/2010, 00h11
asdf007

Citation:

Envoyé par guipe

D'accord et une dernière question :

joueur_licencie(numero_licence,nom_joueur,prenom_joueur,adresse_joueur,ville_joueur,nom_club,elo,classement_championnat)

Ma clé primaire doit obligatoirement être définie en AUTO INCREMENT?

Dans quels cas doit-on le faire ?

Merci !

Tu ne le fais que lorsque tu souhaites que la clé soit gérée toute seule par le SGBD, en prenant des valeurs numériques de 1 jusqu'au maximum que peut supporter ta colonne. Dans ce cas tu n'as pas besoin de préciser la valeur de la clé lors d'un insert. C'est le cas le plus fréquent.

Là tu as un numéro de licence donc l'auto increment est certainement une mauvaise idée. Il faut gérer toi même ta clé, la préciser lors de l'insert et t'assurer qu'elle est unique pour chaque licencié (sans quoi l'insert se vautrera).
02/04/2010, 07h27
RunCodePhp

Salut

Il me semble que tu ne peux pas mettre le champ "numero_licence" en autoincrement, car théoriquement, ce n'est pas toi qui décide de ce numéro, mais la fédération (le terme n'est peut être pas le bon).

Si c'est le cas, alors mettre ce champ "numero_licence" comme clé primaire ne serait pas forcément l'idéal, ce serait mélanger une donnée propre à son activité et une donnée propre au fonctionnement de la Bdd.

Une solution serait de créer un champ spécifique pour le fonctionnement de la Bdd, pour les jointures entre autre :
joueur_licencie(joueur_id, numero_licence, nom_joueur, prenom_joueur, adresse_joueur, ville_joueur, nom_club, elo, classement_championnat)

le champ "joueur_id" serait un auto_increment, mais comme une licence est unique, il faudrait mettre comme contrainte "UNIQUE" sur ce champ "numero_licence".

Pour la table "clubs" il faudrait une clé primaire en auto_incremente, un ID :
clubs(club_id, nom_club, ville_club, adresse_club, pageweb_club, nom_ligue)

Ensuite, si un joueur ne peut appartenir qu'à 1 seul club, alors, il faudrait rajouter l'ID du club dans la table "joueurs" :
joueur_licencie(joueur_id, club_id, numero_licence, nom_joueur, prenom_joueur, adresse_joueur, ville_joueur, nom_club, elo, classement_championnat)

Aussi, le champ "nom_club" de la table "joueurs" est inutile, le nom du club devra être obtenu en faisant des jointures grâce au club_id rajouté. (table joueurs/clubs).
joueur_licencie(joueur_id, club_id, numero_licence, nom_joueur, prenom_joueur, adresse_joueur, ville_joueur, elo, classement_championnat)

Il faudrait peut être retirer le champ "classement_championnat", ce n'est pas une donnée propre à un joueur, il faudrait à mon sens une table spécifique pour le championnat. Faut voir.

Le champ "elo" aussi, je ne sais pas ce que c'est, faudrait voir s'il a sa place dans cette table "joueurs".

Pour la table "ligue_regionale" il faudrait aussi une clé primaire, un ID en auto_incremente :
ligue_regionale(ligue_id, nom_ligue, page_web_ligue).

Ensuite, supprimer le champ "nom_ligue" de la table "clubs". Même chose, le nom devra être obtenu par jointure, grâce au ligue_id.
club(club_id, nom_club, ville_club, adresse_club, pageweb_club)

Question comme ça.
Est que (par hasard) un club ne devrait pas appartenir qu'à 1 seule ligue régionale ?
Si c'est le cas, il faudrait faire comme pour la table "joueur" :
club(club_id, ligue_id, nom_club, ville_club, adresse_club, pageweb_club)

Mais, car il y a un mais.
Ce pose ici la question de l'historique, aussi bien pour la table joueurs, clubs (au minimum).
Il faudra répondre à la question si on veut conserver l'exactitude des données dans le temps en cas de changement, de mouvement.
Exemple :
Si un joueurs en 2009 est licencié dans tel club, (avec une licence), et que l'année d'après il change de club : Que fait on ?
Dans le cas ici, l'historique sera perdue lorsque qu'on va mettre à jour les données du joueur.

De même que si un joueur ne renouvelle pas sa licence, que fait on : Faut il le supprimer ?
Ca dépend du reste de la Bdd, car s'il y a une notion de "joueur contre un autre joueur" (par exemple), une suppression risque de faire planter l'application (voir même une modification).
De même que si on fait des stats, les données supprimées risque de les faussées (voir même une modification).

Pas si simple en faite ...

Ca à été fait au feeling, vite fait à l'instant, je ne peux garantir que cela soit la meilleur approche, faut voir.
S'il y a d'autres contraintes, il faut le dire, ça peu déboucher sur une manière de faire particulière.
Mais une chose est sûr, faut éviter de mélanger des données, voir de dupliquer des données dans plusieurs tables, et utiliser des IDs, des identifiants comme clés primaire, (et non des noms).
02/04/2010, 10h10
guipe

Je liste mes contraintes:

Afin de pouvoir participer aux competitions oficielles, un joueur doit etre inscrit dans un club d'echecs,
et posseder une licence. La dureede vie d'une licence est une annee sportive. Un joueur ne peut pas etre inscrit dans deux clubs pendant la meme saison.

Les coordonnees d'un licencie consistent en quelques coordonnees person-
nelles, le club d'afiliation, le numero de licence, l'Elo, et son classement actuel au championnat.

Les coordonnees d'un club sont : le nom, la ligue d'afiliation, l'adresse, et la page web.

les coordonnees d'une ligue sont :nom et site web.

joueur_licencie(joueur_id(AUTO INC),club_id, numero_licence(UNIQUE), nom_joueur, prenom_joueur, adresse_joueur, ville_joueur, nom_club, elo, classement_championnat)

club(club_id(AUTO INC), ligue_id, nom_club(UNIQUE ?), ville_club, adresse_club, pageweb_club)

ligue_regionale(ligue_id(AUTO INCREMENT), nom_ligue(UNIQUE), page_web_ligue)

Du moment qu'un nom de ligue est unique: exemple ligue PACA(ce sont des ligues régionales).Est-ce nécessaire de mettre un ligue_id? Ne suffit-il pas de mettre nom_ligue en UNIQUE et de l'utiliser comme clé primaire?
Pareil pour numero_licence dans joueur_licencie, ne suffit-il pas de le mettre en UNIQUE et de l'utiliser comme clé primaire?

Par contre pour club je comprends car aucune des informations n'est sure d'etre totalement unique !
02/04/2010, 10h17
guipe

Pour répondre à tes questions:

Question comme ça.
Est que (par hasard) un club ne devrait pas appartenir qu'à 1 seule ligue régionale ?

Oui en effet !

Le champ "elo" aussi, je ne sais pas ce que c'est, faudrait voir s'il a sa place dans cette table "joueurs"

L'elo est le classement des joueurs d'échecs !

Si un joueurs en 2009 est licencié dans tel club, (avec une licence), et que l'année d'après il change de club : Que fait on ?

La licence dure un an, je ne sais pas si je dois modéliser ça dans ma base !
02/04/2010, 10h58
RunCodePhp

Citation:

Du moment qu'un nom de ligue est unique: exemple ligue PACA(ce sont des ligues régionales).Est-ce nécessaire de mettre un ligue_id? Ne suffit-il pas de mettre nom_ligue en UNIQUE et de l'utiliser comme clé primaire?

En 1er, un auto_incremente et la contrainte UNIQUE sont 2 choses différentes, autant dire aucun rapport.
Mettre une contrainte UNIQUE n'est en rien une clé primaire.
Par contre, un auto_increment sera automatiquement unique, c'est le seul point commun.

Après ça, chacun à son approche entre utiliser un champ spcécifique (un ID) un le nom si celui ci est unique.

Mon avis est très radical (il est ce qu'il est), c'est de ne pas mélanger le fonctionnement de la BDD et les informations qui nous sont propre, donc un ID.
La contrainte UNIQUE est pour ma part justement fait pour ça si on en a besoin.
De plus, faire des jointures sur des IDs, un nombre, un entier est plus rapide qu'une chaine de caractère (un nom).
Mais encore, au niveau du code Php, il est de loin plus facile, plus simple de transmettre un ID qu'une chaine de caractère, et encore plus facile, plus sûr même de vérifier un nombre qu'une chaine de caractère.
Ca fait beaucoup de bonnes raisons à mon sens.

Juste un exemple encore, dans le cas ou on utilise un nom comme clé primaire.
Il sera quasi certain que ce nom sera au moins 1 fois, voir même plusieurs fois dans d'autres tables comme clé étrangère, justement pour pouvoir faire des jointures.
Si, pour X ou Y raison un nom doit être modifié, il faudra à tout prix le modifier dans toutes les tables où il se trouve, avec tous les risque d'erreurs, d'oubli qu'il pourrait avoir (l'erreur est humaine).
Si erreur il y a, c'est plantage garanti.

Par contre, si la Bdd, la donnée repose sur un ID, et au autre champ pour le nom, on changera qu'1 seule fois son nom, car il y sera qu'une seule fois, c'est les IDs qui seront comme clés étrangère dans les autres tables.
Bref ... ici, on peu changer le nom sans se préoccuper du fonctionnement de la BDD, on peu même se tromper sur le nom, ça n'aura aucune incidence sur la Bdd.

Il est important aussi qu'au niveau de son code Php, de faire au maximum référence aux IDs, aux clés primaires et étrangères, et non pas aux noms.

Un long discourt, mais il me semble que cela en vaut la peine ;)

Citation:

La licence dure un an, je ne sais pas si je dois modéliser ça dans ma base !

J'en sais trop rien non plus, c'est à toi d'y répondre.
Cette question est directement liée à ce que je disais au niveau de l'historique.
Il est important, voir essentiel de répondre à cette question, la Bdd, sa conception sera radicalement différente selon le cas, et tout le code Php, l'application dans son ensemble même.
Ce n'est pas un détail, loin de là ;)
Il faut bien visualiser se qu'il se passe quand tu feras une modification, et une suppression.
02/04/2010, 12h15
guipe

OK je comprends !

Pour revenir sur l'historique, je ne pense pas qu'il soit nécessaire de la garder.
Si un joueur change de club et bien il change de club, on modifie la donnée directement, on ne conserve pas son ancien club.

Pour ce qui est de la licence, je vais voir.

Merci de ton aide en tout cas !

Voici mon code de création des tables, j'ai du mal à savoir si un champ peut etre NULL ou pas ou si ils doivent etre définis tous comme NOT NULL.
J'ai aussi un problème avec les clés étrangères,dois-je redéfinir les contraintes alors qu'elles ont du déjà etre définies dans la table qui la référence?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
CREATE TABLE joueur_licencie
(
	id_joueur INT NOT NULL AUTO_INCREMENT,
	id_club INT NOT NULL,
	numero_licence INT NOT NULL UNIQUE,
	nom_joueur VARCHAR(20),
	prenom_joueur VARCHAR(20),
	adresse_joueur VARCHAR(50),
	ville_joueur VARCHAR(50),
	elo INT(4),
	classement_championnat INT(4),
	CONSTRAINT pk_id_joueur PRIMARY KEY(id_joueur),
	CONSTRAINT fk_id_club FOREIGN KEY(id_club) REFERENCES club(id_club) ON DELETE SET NULL
);
 
CREATE TABLE club
(
	id_club INT NOT NULL AUTO_INCREMENT,
	id_ligue INT NOT NULL,
	nom_club VARCHAR(20),
	ville_club VARCHAR(50),
	adresse_club VARCHAR(50),
	pageweb_club VARCHAR(50),
	CONSTRAINT pk_id_club PRIMARY KEY(id_club),
	CONSTRAINT fk_id_ligue FOREIGN KEY(id_ligue) REFERENCES ligue(id_ligue) ON DELETE SET NULL
);
 
CREATE TABLE ligue
(
	id_ligue INT NOT NULL AUTO_INCREMENT,
	nom_ligue VARCHAR(50) UNIQUE,
	pageweb_ligue VARCHAR(50),
	CONSTRAINT pk_id_ligue PRIMARY KEY(id_ligue)
);

02/04/2010, 19h22
RunCodePhp

Alors là, ça fait une paye que je n'ai plus pratiqué les intégrités référentielles.
Donc sous réserve ;)

A priori, ça à l'air correcte.
Pour la syntaxe, c'est le trou noir, je ne pourrais pas t'aider.
Pour le principe, et si la mémoire ne me fait pas défaut, il faut effectivement définir la clé, et pour la ou les clés étrangères, il faut définir la table où celle ci est la clé primaire.
C'est grâce à ça que la Bdd pourra faire des suppressions en cascade par exemple.

Pour le "ON DELETE SET NULL" de la table "joueur_licencie
", ça mérite réflexion.
A mon sens il y a contradiction entre le fait de défnir le champ "id_club" NOT NULL et définir à NULL en cas de suppression d'un club qui deviendrait inexistant.

En faite, je ne suis pas partisan de mettre un champ à NULL dans un cas pareil, mais de tout faire pour éviter la suppression du club si celui ci est présent dans une table.
En gros, je ne mettrais pas cette instruction.
A toi de voir.

Si tu veux vraiment verrouiller le truc, créer une procédure stockée pour empêcher la suppression d'un club existant dans la table "joueurs" pourrait être une solution par exemple.
Mais on peu se contenter de le faire au niveau de l'application, c'est plus simple.

Concernant les NULL.
Il y a la valeur nulle, mais aussi une valeur par défaut, ça peut être utile.
(Exemple de syntaxe : classement_championnat INT(4) DEFAULT 1)

La dessus, il y a que toi qui est le mieux placé pour le savoir.
Comme ça au feeling, il y aurait peut être 2 qui accepterait des valeurs nulle.
-> pageweb_club
-> pageweb_ligue
En partant du principe qu'un club ou une ligue peut très bien ne pas avoir de site Web.

Pour le "classement_championnat", peut être une valeur par défaut, peut être nulle ?
J'en sais rien, à toi de voir, ça dépend si tu peux accorder une valeur dans le cas où un joueur s'inscrirait pour la 1ère fois dans un club.

Pour le champ "elo", vu que je ne sais pas ce que c'est, alors ???

Pour les autres, à mon avis ça devrait être obligatoire, donc pas de valeur nulles possible.
Il faut rajouter au champs : NOT NULL
-> nom_joueur, prenom_joueur, adresse_joueur, ville_joueur, etc ...

Petite remarque en passant.
Concernant les valeurs NULL, faudra faire attention du coté de Php, car si on y fait pas gaffe, une valeur vide n'est pas équivalent de NULL du coté de MySQL alors que Php est un peu laxiste sur ce point.
03/04/2010, 01h39
guipe
Merci.

Encore une question.Je veux récupérer le nom du club lorsque je cherche un joueur dans un formulaire.
Je fais :
Code:

1 2 3 $query_nom_club="SELECT nom_club FROM club WHERE nom_club='".$_POST['nom_club']."'"; $result_club=mysql_query($query_nom_club); echo $result_club;
Mais ça ne marche pas.Ou est l'erreur ?

Citation:

Mais ça ne marche pas.Ou est l'erreur ?

C'est pour cette raison que l'on crée des Ids, les clés primaires et étrangères, pour faire les jointures afin de récupérer les données classées dans divers tables.

Citation:

Je veux récupérer le nom du club lorsque je cherche un joueur dans un formulaire.

Ok, mais ta requête se base sur $_POST['nom_club'], qui est le nom d'un club.
Du coup, ça va pas.
Si tu cherche le nom du club d'un joueur, il faut s'appuyer sur une donnée d'un joueur.

Si on se base sur ta requête, (sur la données $_POST['nom_club']), la seule chose qu'on pourra faire, c'est de lister tous les joueurs appartenant à ce club (mais pas 1 joueur).

Je mets la requête quand même :
Code:

1 2 3 4 5 $query_nom_club = "SELECT j.nom_joueur, prenom_joueur FROM joueur_licencie j JOIN club c ON c.id_club = j.id_club WHERE c.nom_club = '".$_POST['nom_club']."'";
Donc une liste de joueurs du club.
Aussi, dans la mesure du possible, il est mieux de faire des recherche en s'appuyant sur un ID, (id_club) plutôt qu'un nom (nom_club).

Et dans le cas où on s'appuie sur une donnée d'1 joueur (avec $_POST['joueur_id']), on pourra rechercher son club :
Code:

1 2 3 4 5 $query_nom_club = "SELECT j.nom_joueur, j.prenom_joueur, c.nom_club, c.ville_club FROM joueur_licencie j JOIN club c ON c.id_club = j.id_club WHERE j.id_joueur = '".(int)$_POST['id_joueur']."'";

03/04/2010, 14h24
guipe

Oui j'aurais trouvé ça plus logique.Mais dans mon énoncé il m'est demandé de faire la recherche par rapport au nom du club !

Lorsque je veux créer un licencié, j'ai envie de récupérer l'id du club par rapport au nom du club que j'ai mis dans le formulaire :

Donc je fais :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
 
include("connection_base.php");
 
$query_id_club="SELECT id_club FROM club WHERE nom_club='".$_POST['nom_club']."'";
$id_club=mysql_query($query_id_club) or die("Echec de la requête");
 
while($insert_id=mysql_fetch_assoc($id_club))
{
	echo'coucou';
	$query="INSERT INTO joueur_licencie VALUES ('','".$insert_id['id_club']."','".$_POST['numero_licence']."','".$_POST['nom_joueur']."','".$_POST['prenom_joueur']."','".$_POST['adresse_joueur']."','".$_POST['ville_joueur']."','".$_POST['elo']."','".$_POST['classement_championnat']."'";
	mysql_query($query);
}
?>

Mais ça ne marche pas.Je n'obtiens aucune nouvelle insertion !

03/04/2010, 21h33
guipe

Message édité car j'ai résolu mes problèmes.Merci beaucoup !