khana/personnal_docs/Wantedfunctionnality.md

2.9 KiB

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 ?