66 lines
2.9 KiB
Markdown
66 lines
2.9 KiB
Markdown
|
# Fonctionnalités souhaitées
|
||
|
|
|
||
|
|
## Utilisateurs, entraineurs et gymnastes
|
||
|
|
Plusieurs personnes doivent pouvoir utiliser l'application : chaque entraineur ! Un entraineur est une personne (user donc) qui est associée à, au moins, un cours. Ou plutôt, chaque cours doit avoir au moins un entraineur (un cours pour avec 1+ entraineurs, un entraineur peut donner plusieurs cours).
|
||
|
|
|
||
|
|
Un user est un entraineur et vice-versa.
|
||
|
|
|
||
|
|
Un gymnaste peut également être un entraîneur et donc un utilisateur. Entraineur et gymnaste ont beaucoup de champs en commun :
|
||
|
|
|
||
|
|
- lastname
|
||
|
|
- firstname
|
||
|
|
- birthdate (pas obligatoire mais utile pour une entraineur)
|
||
|
|
- sexe
|
||
|
|
- niss
|
||
|
|
- address
|
||
|
|
- box
|
||
|
|
- postal
|
||
|
|
- city
|
||
|
|
- phone (pas obligatoire ni pour un gym ni pour un entraineur)
|
||
|
|
- gsm
|
||
|
|
- email
|
||
|
|
- ffgid
|
||
|
|
- active
|
||
|
|
- picture
|
||
|
|
|
||
|
|
Il reste quelques champs (trois) qui ne sont utilisés QUE pour les gymnastes :
|
||
|
|
|
||
|
|
- gsmm
|
||
|
|
- gsmp
|
||
|
|
- orientation
|
||
|
|
|
||
|
|
Alors...
|
||
|
|
|
||
|
|
Combien de tables dois-je avoir ?
|
||
|
|
|
||
|
|
- deux : user et gymnast avec une relation 1 - 1 ?
|
||
|
|
- trois : user, trainer et gymnast avec une relation 1 - 1 | 0 ?
|
||
|
|
|
||
|
|
Et comment les lier ?
|
||
|
|
|
||
|
|
==> il y a tellement peu de différences entre les deux (entraineur et gymnaste) que je pense qu'une seule table ()pour les deux types de personne) peut largement suffire quitte à ajouter des champs pour flagguer s'ils sont gymnaste (True/False) et entraineur (True/False). Ensuite, on pourrait lier la table USER de Django avec la table (renommée en PEOPLE, par exemple) pour en plus pouvoir signaler quelles personnes sont, en plus, des utilisateurs du site. On aurait donc DEUX tables en tout avec une liaison O2O.
|
||
|
|
|
||
|
|
Qu'en penses-tu ?
|
||
|
|
|
||
|
|
|
||
|
|
## Liste de présences ?
|
||
|
|
Grâce aux tables Group, Subgroup et aux tables de liaisons vers les gymnastes et le club, il est possible de générer des feuilles de présence.
|
||
|
|
|
||
|
|
Ces listes de présence sont générées par rapport au cours (jour), aux (sous-)groupes et aux gymnastes. Sur base de cela, le site génére une liste des jours ou il devrait y avoir cours. La notion importante est "***devrait*** avoir cours". En effet, il est possible que un cours n'ait pas pu être donné car l'entraineur n'était pas disponible, la salle était indisponible, … etc.
|
||
|
|
|
||
|
|
Je souhaite pouvoir faire des statistiques précises (le plus possible) il est important de pouvoir connaitre avec précision les cours donnés ou pas afin de pouvoir tenir compte des vacances (toussaint, noel, carnaval, paques, grande vacances, jours fériés, ...).
|
||
|
|
|
||
|
|
Comment stocker cette informations ?
|
||
|
|
|
||
|
|
Design proposé :
|
||
|
|
|
||
|
|
ID ID (PK)
|
||
|
|
datebegin date
|
||
|
|
dateend date
|
||
|
|
information text
|
||
|
|
|
||
|
|
Pour la génération des listes de présences, il faudrait combiner la table COURSES, les jours générés et les records de ma table ci-dessus.
|
||
|
|
|
||
|
|
Qu'en penses-tu ?
|
||
|
|
|
||
|
|
De manière générale, j'ai beaucoup de mal avec la complémentarité de mes données datées : dois-je stocker que ce qui **est** ? Dois-je stocker que ce qui **n'est pas** ? Dois-je stocker **les deux** ?
|