Discussion :

[folyonais]

salut à tous et toutes !
je me suis mis dans l'idée de refaire le site du club de badminton pour faciliter la gestion ...
et je ne pensais pas galérer autant sur le mcd (que j'ai mis en piece jointe).

j'aimerais si possible que vous me le validiez (ou tirez les oreilles)
je pense qu'il y a de GROSSES erreurs. (5 ans sans faire de MCD , c'était temps de s'y remettre...)

j'ai du mal a modeliser : "un joueur peut faire parti d'une equipe interclub et en changer au cours des annees"

j'aimerais associer des photos aux tournois / rencontre interclub. Suis je obliger de créer les entités photos_interclub ET photo_tournois ? (de meme pour les commentaires)
ou y a t-il un moyen de créer une seule entité photo / commentaire qui serait liée à ces 2 evenements


après ça restera à gérer les résultats des matchs de rencontre interclub, je ne vois pas trop comment faire puisqu'il y a des match de double et des simples)

j'apprécierai tout commentaires / remarques sur mon shema

merci

[CinePhil]

1) Table joueurs
- Pourquoi type_joueur_id apparaît 2 fois dont une fois participant à la clé primaire ?

- Civilité en VARCHAR(45), c'est pas un peu surdimensionné ?
D'ailleurs la civilité peut être externalisée dans une autre table car c'est une donnée extrêmement répétitive d'une ligne à l'autre.

- Code postal en VARCHAR(10) idem, à moins que ce soit un club internationnal, les codes postaux français sont sur 5 caractères.

- La ville devrait elle aussi être externalisée pour éviter d'avoir plusieurs fois la même ville avec des orthographes différentes (Saint-Etienne, St-Etienne, Saint Étienne...)

- Idem pour la nationalité qui peut être externalisée.

2) Association entre comptes et joueurs
Telle qu'elle est définie sur le schéma, elle signifie qu'un compte peut appartenir à plusieurs joueurs. Normal ?

3) Table Comptes
- Le type devrait être externalisé, pour les raisons déjà évoquées.
- Plutôt que de stocker une image d'avatar dans la BDD, il vaut mieux y stocker le chemin vers le fichier de l'image. C'est moins gourmand en ressources pour le SGBD.

4) Table mp
- Je suppose qu'il s'agit de "messages privés" ? Il faudrait choisir un nom de table plus signifiant.
- Un contenu de 45 caractères au maximum, c'est pas un peu faible ?

5) Table composition_equipe_interclub
- Les identifiants des tables joueurs et equipe_interclub étant de type INT, leur correspondance dans cette table ne peut pas être de type VARCHAR !

6) Table tournois
- Externaliser la ville (voir plus haut).
- Que sont cout_un_tab et cout_deux_tab ? S'il s'agit d'un coût en euros, il vaut mieux utiliser un type INTEGER ou DECIMAL.

7) Table Photos_tournois
- Idem précédemment, id_tournoi ne peut pas être de type VARCHAR
- Idem précédemment, ne pas stocker la photo dans la BDD mais seulement le chemin vers le fichier de la photo.

8) Table Commentaire_photo
- Idem précédemment, id_photo ne peut pas être de type VARCHAR

9) Table Inscription_tournoi
- Idem précédemment, id_tournoi et id_joueur ne peuvent pas être de type VARCHAR.
- Les catégories devraient être externalisées.
- Utiliser plutôt un DECIMAL qu'un FLOAT pour un coût.

10) Table Gymnases
- Idem précédemment, externaliser la ville.
- Idem précédemment, ne pas stocker la photo dans la BDD.
- Une adresse en VARCHAR(45) ça risque d'être un peu juste.

11) Table créneaux
- Un jour en VARCHAR(45), s'il s'agit du jour de la semaine, c'est trop grand et il vaut mieux l'externaliser. Si c'est une date, utiliser le type DATE.
- Heure_debut et heure_fin devraient être de type TIME.
- Idem précédemment, gymnase_id ne peut pas être de type VARCHAR !

12) Association entre creneaux et joueurs / table inscription_creneaux
- Attention au fait que rien n'interdit qu'un joueur s'inscrive à un créneau qui n'est pas de son type. En toute rigueur, il faudra un trigger pour valider l'inscription au créneau en fonction du type du joueur = type du créneau.
- Si l'identifiant de creneaux est de type INT, il faut que l'identifiant de la table associative soit du même type.

13) Table rencontres_interclubs
- Idem précédemment, creneau_id devrait être de type INT.
- Idem pour club_adverse.

Remarques complémentaires :
- D'une manière générale, on nomme en principe les tables au singulier.
- Il manque le repère des clés étrangères dans les tables, donc probablement leur définition, alors que celles-ci sont générées automatiquement par MySQL Workbench quand on fait une association entre deux tables.

Bon courage pour la suite.

[folyonais]

Bonjour,
un grand merci pour votre retour et le temps passé
j'avais fait peu attention aux type des champs, mon problème se portait plus sur la relation entre les tables.
je vais reprendre vos points un et créer une nouvelle version.
encore un grand merci
A.T

[folyonais]

Bonjour,
j'ai enfin pu retrouver du temps pour me remettre sur ce projet. j'ai corrigé tous les points cité ci dessus (un GRAND MERCI), je post demain le nouveau jpg correspondant à mon shema de table. j'ai mal utilisé mysql workbench d'ou les erreur de type de clef ect... :/

1) Table joueurs
- Pourquoi type_joueur_id apparaît 2 fois dont une fois participant à la clé primaire ?

j'ai pas du attaché le bon fichier, l'erreur a été corrigée

- Civilité en VARCHAR(45), c'est pas un peu surdimensionné ?
D'ailleurs la civilité peut être externalisée dans une autre table car c'est une donnée extrêmement répétitive d'une ligne à l'autre.

vous avez raison, il est préferable d'externaliser cette donnée, j'ai corrigé

- Code postal en VARCHAR(10) idem, à moins que ce soit un club internationnal, les codes postaux français sont sur 5 caractères.

vous avez encore raison , j'ai corrigé

- La ville devrait elle aussi être externalisée pour éviter d'avoir plusieurs fois la même ville avec des orthographes différentes (Saint-Etienne, St-Etienne, Saint Étienne...)

vous avez raison, je comptais faire une table annexe contenant la liste des code postaux en France et les villes associés, mais je ne sais pas comment modeliser ça. Cette table aurait la structure id / code postal / ville.

- Idem pour la nationalité qui peut être externalisée.

corrigé

2) Association entre comptes et joueurs
Telle qu'elle est définie sur le schéma, elle signifie qu'un compte peut appartenir à plusieurs joueurs. Normal ?

grosse erreur de ma part, merci d'avoir relevé, j'ai mis une association "1-1"

3) Table Comptes
- Le type devrait être externalisé, pour les raisons déjà évoquées.
- Plutôt que de stocker une image d'avatar dans la BDD, il vaut mieux y stocker le chemin vers le fichier de l'image. C'est moins gourmand en ressources pour le SGBD.

type : ce champs n'a plus rien a faire ici , je l'ai externalisé dans la table groupe qui permet de stocker mes different type de compte admin ect ..
image : je m'etais posé la question pour les images, je ne conaissais pas l'impact sur les perfs, je stockerai donc le lien de l'image

4) Table mp
- Je suppose qu'il s'agit de "messages privés" ? Il faudrait choisir un nom de table plus signifiant.
- Un contenu de 45 caractères au maximum, c'est pas un peu faible ?

corrigé

5) Table composition_equipe_interclub
- Les identifiants des tables joueurs et equipe_interclub étant de type INT, leur correspondance dans cette table ne peut pas être de type VARCHAR !

c'etait corrigé dans la bonne version, désolé

6) Table tournois
- Externaliser la ville (voir plus haut).
- Que sont cout_un_tab et cout_deux_tab ? S'il s'agit d'un coût en euros, il vaut mieux utiliser un type INTEGER ou DECIMAL.

ville : j'ai le meme que pour joueur
cout : oui c'est bien le prix pour jouer sur un ou 2 tableaux, j'ai corrigé

7) Table Photos_tournois
- Idem précédemment, id_tournoi ne peut pas être de type VARCHAR
- Idem précédemment, ne pas stocker la photo dans la BDD mais seulement le chemin vers le fichier de la photo.

corrigé

8) Table Commentaire_photo
- Idem précédemment, id_photo ne peut pas être de type VARCHAR

corrigé

9) Table Inscription_tournoi
- Idem précédemment, id_tournoi et id_joueur ne peuvent pas être de type VARCHAR.
- Les catégories devraient être externalisées.
- Utiliser plutôt un DECIMAL qu'un FLOAT pour un coût.

corrigé : merci pour l'info du "decimal", je ne savais pas

10) Table Gymnases
- Idem précédemment, externaliser la ville.
- Idem précédemment, ne pas stocker la photo dans la BDD.
- Une adresse en VARCHAR(45) ça risque d'être un peu juste.

corrigé

11) Table créneaux
- Un jour en VARCHAR(45), s'il s'agit du jour de la semaine, c'est trop grand et il vaut mieux l'externaliser. Si c'est une date, utiliser le type DATE.
- Heure_debut et heure_fin devraient être de type TIME.
- Idem précédemment, gymnase_id ne peut pas être de type VARCHAR !

corrigé

12) Association entre creneaux et joueurs / table inscription_creneaux
- Attention au fait que rien n'interdit qu'un joueur s'inscrive à un créneau qui n'est pas de son type. En toute rigueur, il faudra un trigger pour valider l'inscription au créneau en fonction du type du joueur = type du créneau.
- Si l'identifiant de creneaux est de type INT, il faut que l'identifiant de la table associative soit du même type.

corrigé, il faudra que je veille au point un et voir comment faire ça

13) Table rencontres_interclubs
- Idem précédemment, creneau_id devrait être de type INT.
- Idem pour club_adverse.

corrigé

Remarques complémentaires :
- D'une manière générale, on nomme en principe les tables au singulier.
- Il manque le repère des clés étrangères dans les tables, donc probablement leur définition, alors que celles-ci sont générées automatiquement par MySQL Workbench quand on fait une association entre deux tables.

Effectivement , il va falloir que je reprenne toutes les relations entre mes tables, je n'ai pas utilisé mysql worbench correctement, j'ai tout fait a la main, je corrige ça demain et post un nouveau export . j'ai 3 problemes de modelisations encore que je n'arrive pas à resoudre malgré plusieurs heures passées dessus

Bon courage pour la suite.

merci

[folyonais]

Bonjour à tous et toutes

j'aurais besoin encore d'un petit coup de main.
j'ai modifier mon shema :
- réaliser toutes les modifications (j'espere) conseillées par Cinéphil
- supprimer la gestion de tournois (trop compliqué et pas utile je pense au final)
- ajouter 2 fonctionalités :
mailing list : les dirigeants pourront envoyés des mails aux personnes inscrites aux differentes mailing liste. Ces mailing liste vont representer par exemple "tous les joueurs competiteurs", "tout les joueurs jouant sur tel creneau horaire, tous les joueurs faisant le siiterclubs ect" je ne sais pas si j'ai bien modéliser ..

sondage : cette fonctionalité nous est tres utile ! qui amene la biere a l'interclub par exemple . Mais pour la modeliser, c'est la catastrophe pour moi. De la meme façon que les mailing list, les sondages vont etre ouverts a tous ou à un certain nombre de personnes, un type de joueur ect. Chaque sondage a une question et des réponses proposées. Suivant le type de sondage (choix mutliple ou pas ) , le joueur peux voter pour une ou plusieurs reponses c'est la que je coince. une reponse ça va ... plusieurs je vois pas comment mettre ça en place :'(

- j'ai créé une table dossier pour avoir un historique des inscriptions.
un joueur a un dossier actif (année en cours) et des anciens dossiers precedentes années). Chaque dossier est lié a un type de joueur / type inscription (adulte competiteur, adulte loisir ect). Pour chaque type on a un ou plusieurs creneaux. Le joueur peut s'inscrire a un ou plusieur creneaux suivant son type d'inscription.

- les villes / code postal. j'ai un pb pour lier ça à la table joueur. je m'explique. Soit je supprime mes champs code postal / ville dans joueur et je met un idville en clef etrangere mais ça implique que j'ai toute les villes en database , ça laisse aucune erreur...
je voyais plutot cette table qui me servirait à alimenter mes 2 champs en utilisant de l'ajax ect ...

voila apres ça , je devrais pouvoir commencer les devs


un grand merci d'avance pour votre aide