Je travaille actuellement sur le développement d’une application web destinée à répondre à un besoin concret exprimé par un club de football : centraliser et simplifier la gestion de ses équipes, joueurs, événements, convocations et présences.
Le projet est développé avec Java et Spring Boot pour le backend, PostgreSQL pour la base de données et React pour le frontend.
Avant de commencer à développer les différentes fonctionnalités, une première question s’est posée : comment structurer les données du club de manière cohérente et suffisamment évolutive pour que l’application puisse réellement être utilisée ?
Partir du fonctionnement du club, pas de la base de données
Je ne suis pas partie directement de PostgreSQL en me demandant quelles tables créer.
J’ai d’abord essayé de traduire le fonctionnement réel du club en données.
Le club possède plusieurs équipes. Chaque équipe regroupe des joueurs et évolue dans une catégorie et un niveau donnés pour une saison. Les équipes participent ensuite à différents événements, notamment des entraînements et des matchs.
Pour certains événements, le staff doit pouvoir convoquer des joueurs et suivre leur présence.
À partir de ces besoins, plusieurs concepts métier sont apparus naturellement :
Équipe
Joueur
Utilisateur
Événement
Convocation
Présence
Le véritable travail de conception commence alors : comment ces éléments sont-ils liés ?
Par exemple, une équipe possède plusieurs joueurs, tandis qu’un joueur appartient à une équipe dans un contexte donné. Une équipe possède également plusieurs événements. Un événement peut concerner plusieurs joueurs par l’intermédiaire des convocations.
C’est cette analyse qui m’a conduite vers un modèle relationnel.
Pourquoi PostgreSQL ?
Les données de l’application sont fortement liées entre elles.
Une convocation n’a de sens que si elle correspond à un événement et à un joueur existants. Un événement est rattaché à une équipe. Les informations doivent rester cohérentes lorsqu’elles évoluent.
Commentaires