Forum d'entraide PHPFrance

Bonjour à tous,

Je suis actuellement dans l'élaboration de mon projet qui ets la gestion d'une équipe de basket,
Et viens le moment crucial ou je dois préparer ma base de donnée.
mais n'ayant jamais aboutie de gros projet, je n'ai pas l'expérience dans le donnée de la BDD

Ma question principale :
Mieux vaut 'il regrouper un maximum de table en une seule (dans la mesure du possible)
En effet nombreuses de "mes tables" sont reliés les unes aux autres.

Voici des exemples de tables :

- Membres (login - mdp - email etc...)
- Equipe (informations sur l'équipe .... ) Ces 2 tables pourrait être éventuellement regroupé.

- Economie (dépenses + recettes) qui pourrait être regroupé avec équipe

- Joueurs (tout les joueurs (avec un comme champ les caractéristique + leur propriétaire)).

Etc
Etc


Donc mieux vaut il des tables claires ou au contraire afin de limiter les requêtes en regrouper certaines ?

merci d'avance de votre aide,

Bonne journée

Comment repondre a cette question ????
Je dirais que une bonne structure de base permet de faciliter la maintenance.
Tout mettre dans une table n'est pas une bonne methode. Parfois il faut mieux mettre certaines informations dans une meme table mais pas toutes.
Je dirais que c'est plus rentable de mettre tes joueurs hors des equipes et des les lier.
Tu pourra ainsi assossier un joueur a une equipe ou a plusieurs selon comment est fait ta base de donnees.

Normalement, dans une base propre, merisienne et tout et tout, la première chose à faire, c'est de ne pas répéter les données. Ainsi, si tu mélanges les infos de l'équipes à celle des membres, tu auras pour chaque membre un champ info_de_l_equipe et ca deviendra vite une vrai galère pour mettre à jour une donnée si elle est répétée en plusieurs endroits

Dans un premier temps liste les éléments qui nécessitent d'avoir une table associée (équipes, membres, rencontres, etc.) et regroupe dans chaque les données qui leurs sont propres : un membre a un (et un seul) nom, un (et un seul) prénom, il appartient à une (et une seule) équipe, mais il peut avoir joué plusieurs match (on va donc faire une table spéciale pour les match), et il n'a pas d'info sur l'équipe, il n'a pas d'économie, etc.

Ryle, ta réponse tout comme la première est extrèmement interessante.

Par contre j'ai peur de ne pas saisir toutes les subtibilités de ton exemple.
Pourrais tu préciser s'il te plait.

Merci en tout cas de vos réponses (rapide !)

EDIT :
Si il ya une table équipe et une table membre, il faudra alors un champ qui les relis.

Tel que dans la table équipe le champ propriétaire qui équivaut au pseudo déja enregistré dans la table membre. A moins que les id des entrés correspondent et donc l'id 124 de la table membre est bien le proprio de l'équipe dont l'id est 124 ..

Bah en gros mon exemple consiste à dire qu'il faut regrouper de manière à pas multiplier. La première chose à faire étant d'identifier les "objets" ou "ensembles" les plus importants. (Le plus simple pour cela étant généralement d'écrire clairement ce que tu veux faire, ca les fait ressortir assez facilement

Ex : "Je veux gérer les matchs de basket entre plusieurs équipes, et suivre les statistiques des joueurs pour chaque match."
=> une table match, une table equipe, une table joueur, une table stat.

Tu peux alors commencer à décrire tes tables :
- un match est défini par : une date, deux équipes, un score, ... (et bien sur un identifiant unique)
- une équipe est définie par : (un id unique), un nom, un logo, ...
- un joueur est défini par : (son id unique), son nom, son prénom, ...
- un enregistrement statistiques comprend : le nombre de rebonds off, déf, passes décisives, ...

Etape suivante, les cardinalités (comment les données sont liées entres elles) :
* match {2..2} --- {0..n} équipe // un match est joué par obligatoirement 2 équipes, une équipe peut avoir joué 0 à n match
=> je vais avoir deux champs dans la table match pour identifier les deux équipes correspondantes
* équipe {5..n} --- {1..1} joueur // une équipe a minimum 5 joueurs, maximum n joueurs avec les remplacants, en revanche un joueur appartient à une et une seule équipe.
=> je vais avoir un champ dans la table joueur pour identifier l'équipe
* joueur {0..n} --- {1..1} stat // un joueur peut avoir de 0 à n statistiques (1 par match ou il joue), une statistique est associée à un et un seul joueur
=> je vais avoir un champ dans la table stat pour identifier le joueur
* match {10..n} --- {1..1} stat // un match aura 2 équipes, donc minimum 2*5 = 10 joueurs, donc logiquement 10 stats associées. En revanche les stat d'un joueur ne sont vallable que pour un et un seul match.
=> je vais avoir un champ dans la table stat pour identifier le match

En gros, si j'ai un nombre fini de possibilités d'un côté ou de l'autre, j'ajoute un champ. Si j'ai un nombre infini (0..n) de possibilité de chaque côté, j'ajoute une table de liaison qui reprend les identifiants de chaque table.

Alors bien sur, tout n'est pas figé non plus. On pourrait très bien envisager avoir un champ date dans la table statistique alors que l'info est déjà présente dans la table match parce que c'est beaucoup plus simple pour voir directement les perf d'un joueur sur un mois, plutôt que de devoir croiser avec la table des matchs (de toute façon c'est pas une donnée qui bougera beaucoup )


Bon c'est pas forcément évident de résumé les principes de conception d'une bdd, mais ca te donnera au moins un début d'approche de la chose

Superbe !
Merci d'avoir pris autant de temps (et d'exemple) pour m'expliquer !
J'ai imprimé la page et avec comme support, je vais pouvoir créer mes tables sur papier.

Quelque chose qui me tracassait, est comment gérer le classement ? car il y a à la fois la division et la place dans cette division. Il faudrait donc 2 champs dans "equipe" l'un division et l'autre "place".

Et concernant tes exemples, tu mettrais donc equipe et membre dans une seul et même table.

MErci encore !

Si l'équipe n'appartient qu'à une seule division ouep, idem si elle ne peut avoir qu'un seul classement dans cette division

Sinon c'est quoi pour toi un membre par rapport à un joueur ?
Est ce qu'il s'agit d'une propriété spécifique à chaque équipe (dans ce cas ouep, tu peux coller ça dans la table équipe), ou bien d'une entité spécifique pouvant être dissociée de l'équipe (dans ce cas il lui faut sa table à lui) ou encore est-ce un joueur avec des infos spécifiques (dans ce cas on peut étendre cette table ou envisager une nouvelle table liée à celle des joueurs) ?

Joueur = Tout les joueurs qui seront généré et qui donc appartiendront à des équipes respectifs.

Ce qui veut dire une table spécifique pour l'ensemble des joueurs.

Membre = Les visiteurs du sites (qui sont loggés) et qui on chacun une seule équipe.

Donc je peux fusionner avec la table équipe.
Par contre elle sera lourde, cela ne poserait pas de problème.
Et en partant dans cette optique, je pourrais fusionner avec la table "économie puisque ce sera une spécificité à chaque équipe (la valeur).

Bah c'est un peu comme tu le sens aussi... pour moi un membre est une entité à part entière, complètement indépendante de l'équipe. Donc je leur ferais une table dédiée, et j'ajouterais dans la table équipe un id_membre pour savoir à qui elle appartient.

L'avantage c'est que ca rend ta base plus évolutive si un jour tu veux ajouter autre chose que la gestion d'équipes, ou permettre de gérer plusieurs équipes, ou autre...

En revanche, en fonction de ce que contient ton attribut économie, si c'est juste le budget de l'équipe à un instant T, alors oui, ca fait partie des propriétés d'une équipe et tu peux l'inclure à cette table. Ou alors considérer que cette info est liée au membre, quelle que soit son équipe et la lui affecter, etc. Là c'est à toi de savoir fonctionnellement ce que tu veux faire

1 / Va pour l'id membre
2/ Pour l'économie je me tate encore car comme tu l'as dit soit je fais une table à part avec une nouvelle fois un id_membre.
Soit j'incorpore à l'équipe.
Etant donné qu'il y aura tout de même plusieurs paramêtres dans l'économie je pense opter pour une table séparé.

Merci de tout tes conseils, et si j''ai pas de nouvelles questions d'ici ce soir je mettrais le sujet en résolus.


PS:

ça serait plus facile pour toi de voir du coté de google avec les mots clé MCD(Modèle conceptuel des données), merise, entité-association.
Tu pourras mieux formaliser la création de ta base de données plutot que de choisir aléatoirement que telle ou telle donnée réside dans une table et pas une autre.