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 .. smart ?

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

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.

Salut et bienvenue au club!

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.

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?

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.

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

Players (Id_Player, Playername, password, Email)
RegTournoi (Id_Tournoi, Id_Player)
Tournoi (Id_Tournoi, Date_Tournoi, Participants, Classement, Limite_Reg)

RegTournoi sert à enregistrer les participants pendant les inscriptions
Tournoi 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 ?

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 :
- Player : qui contient toutes les infos relatives aux joueurs
idPlayer, nom, prenom, login, password, etc.
- Tournoi : qui contient toutes les infos relatives aux tournois
idTournoi, nom, lieu, date, etc.
- RegTournoi : 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 :
idPlayer, idTournoi, 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

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 clés étrangères 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 clé primaire ?