OK, je vois où tu veux en venir.

Le seul défaut que je vois à ce type d'organisation mais qui n'en est peut être pas un, c'est la surcharge de la table RegTournoi.

A partir de combien d'entrées peut-on dire qu'une table est overbookée ?

Autre question, lorsque tu parles de Foreign Key, c'est d'un point de vue "papier" uniquement?

A savoir que lorsque je crée mes tables sous MYSQL, je peux indiquer que les champs RegTournoi.idTournoi et RegTournoi.IdPlayer sont des [b]clés étrangères[/b] ou c'est uniquement de la théorie en sachant que ce sont des références existantes dans d'autres tables dont elles sont [b]clé primaire[/b] ?

Bah euh... presque... je vois pas trop l'intérêt de l'info participant dans le tournoi.... c'est en double par rapport à la table RegTournoi et c'est moins pratique à controler/requêter/modifier... Pour moi tu devrais avoir deux tables principales et une de liaison :
- [b]Player [/b]: qui contient toutes les infos relatives aux joueurs
[u]idPlayer[/u], nom, prenom, login, password, etc.
- [b]Tournoi [/b]: qui contient toutes les infos relatives aux tournois
[u]idTournoi[/u], nom, lieu, date, etc.
- [b]RegTournoi[/b] : qui contient toutes la correspondance entre les joueurs et les tournois (qui a joué quand) et éventuellement toutes les infos relatives à la participation du joueur dans ce tournoi :
[u]idPlayer, idTournoi[/u], classement_pour_ce_tournoi, nb_points, ???
idPlayer étant une clé étrangère (FK) vers le champ idPlayer de la table Player
idTournoi étant une clé étrangère (FK) vers le champ idTournoi de la table Tournoi
idPlayer, idTournoi etant la clé primaire de cette table

Au final, voici la structure de la BDD avec laquelle je me trouve :

[i]Players [/i](Id_Player, Playername, password, Email)
[i]RegTournoi [/i](Id_Tournoi, Id_Player)
[i]Tournoi [/i](Id_Tournoi, Date_Tournoi, Participants, Classement, Limite_Reg)

[b]RegTournoi [/b]sert à enregistrer les participants pendant les inscriptions
[b]Tournoi [/b]sert à contenir les infos d'un tournoi pour les inscriptions et à y insérer la liste globale des participants après évenement ainsi que le classement.

Cela vous parait-il cohérent ?

Merci pour ta réponse professorale!

Si je comprends bien, je conserve ma table Membres et Tournoi si ce n'est que cette dernière devrait se présenter de la façon Tournoi (Id_Tournoi, Id_Membre).

Aussi, je peux créer une table Tournoi2 (Id_Tournoi, Participants) lorsque les inscriptions au tournoi sont finalisées et que je veux y faire une sorte de "sum up" si jamais je décide de vider la table Tournoi si jamais il venait à y en avoir trop. Possibilité également d'y insérer un champ Classement, etc.

C'est ça? 8-)

[quote="Ryle"]Un membre peut participer de 0 à n tournois, et un tournoi peut avoir de 0 à n participants. La meilleure solution lorsque tu rencontres ce genre de cardinalité consiste à créer une table intermédiaire contenant l'identifiant du tournoi et celui du membre (le couple des deux formant la clé primaire de ta table)

Un "SELECT ... WHERE idTournoi = xxx" te donnera la liste des id des membres qui ont participé et un "SELECT ... WHERE idMembre = xxx" te donnera la liste des tournois auxquels un membre a participé.

Si tu as un nouvel inscrit, tu inseres une ligne, si tu as un désistement tu supprime la ligne :)

Tu conserves ainsi l'intégrité de ta base de données, chose que tu n'aurais pas si tu concaténais tes id. Tu n'es pas non plus limité en nombre de participants ou de tournois possible alors qu'un champ a forcément une taille limite (aussi long soit-il). Et tu ne te prends pas la tête à coder pour retrouver une donnée à supprimer au milieu de ta chaine.[/quote]

Salut et bienvenue au club! :wink:

Sur la table tournoi, j'ajouterais une colonne id_membre qui serait une clé d'index reprenant l'identifiant de la colonne membres.id_membre.

Un membre peut participer de 0 à n tournois, et un tournoi peut avoir de 0 à n participants. La meilleure solution lorsque tu rencontres ce genre de cardinalité consiste à créer une table intermédiaire contenant l'identifiant du tournoi et celui du membre (le couple des deux formant la clé primaire de ta table)

Un "SELECT ... WHERE idTournoi = xxx" te donnera la liste des id des membres qui ont participé et un "SELECT ... WHERE idMembre = xxx" te donnera la liste des tournois auxquels un membre a participé.

Si tu as un nouvel inscrit, tu inseres une ligne, si tu as un désistement tu supprime la ligne :)

Tu conserves ainsi l'intégrité de ta base de données, chose que tu n'aurais pas si tu concaténais tes id. Tu n'es pas non plus limité en nombre de participants ou de tournois possible alors qu'un champ a forcément une taille limite (aussi long soit-il). Et tu ne te prends pas la tête à coder pour retrouver une donnée à supprimer au milieu de ta chaine.

Bonjour,

Je dispose de 2 tables :

Membres (Id_Membre, Pseudo, password, email)
Tournoi (Id_Tournoi, Participants)

J'ai un doute sur l'organisation de ma base de données.
Je souhaiterais tout simplement faire une liste des participants à un tournoi suite à leur inscription sur un site dédié.

Ainsi, la solution la plus efficace consiste t-elle à insérer avec des séparateurs la liste des participants dans le champ Participants de la table Tournoi ?

Ou il existe une solution beaucoup plus .. [i]smart [/i]? :)

NB : le nombre de participants peut être complètement aléatoire
Merci pour vos réponses.