Base de données SQL de la NoteKfet2015
Cette page explique comment est organisée la base de données de la NoteKfet2015. Si ce n'est pas ce que vous cherchiez, allez demander votre chemin ici.
Sommaire
Structure de la base de données
Le champ effectif dans la base est spécifié entre crochets (avec éventuellement des précisions)
Comptes
Table comptes
Informations sur les adhérents/clubs.
Identifiant BDE (numéro de carte) [idbde PRIMARY KEY]
Type (personne, club, login spécial) [type \in {"personne","club","special"}]
Nom de note [pseudo UNIQUE]
Mot de passe (hashé en md5) [passwd]
- NB : vaut "*" pour les comptes qui ne peuvent pas se connecter (comme Bde)
Solde ( Les soldes sont stockés en centimes !) [solde]
Nom [nom]
Prénom [prenom]
Numéro de téléphone [tel]
Adresse mail [mail]
Adresse IRL [adresse]
Fonction au sein du bde [fonction]
Normalien ou non [normalien]
Problème de santé [pbsante]
Numéro de sécurité sociale [numsecu]
aid ou cid (selon que type='club' ou 'personne') [idcrans] (-1 s'il en a pas (c'est aussi la valeur par défaut))
Droits (comma-separated) [droits] → voir l'API pour la liste des droits
Surdroits (comma-separated) : surdroit i => je peux donner/enlever le droit i [surdroits]
Droit supreme : permet de donner/retirer les surdroits [supreme]
Périodicité des rapports mail (en jours) [report_period DEFAULT -1] (-1 ou 0=pas de rapports)
Date du dernier rapport (pour savoir ce qu'il faut mettre dans le rapport) [previous_report_date]
Date du prochain rapport [next_report_date] (champs inutilisé)
Bloqué ou non (note inutilisable) [bloque]
Id de la dernière adhésion [last_adhesion]
Un commentaire quelconque [commentaire]
Les adhérents qui ne veulent pas de rapport (period=-1) ont "01/01/2042 00:13:37" dans next_report_date
Table préinscriptions
Informations nécessaires à une inscription, qui doit ensuite être validée pour être effective.
Identifiant de préinscription (id temporaire) [preid PRIMARY KEY]
Type [type] (cf comptes)
Nom [nom]
Prénom [prenom]
Numéro de téléphone [tel]
Adresse mail [mail]
Adresse IRL [adresse]
Normalien [normalien]
Problème de santé [pbsante]
Numéro des sécurité sociale [numsecu]
aid/cid [idcrans]
Section [section]
Table adhesions
Une entrée pour chaque adhérent chaque année, si il a adhéré.
NB: la section de l'adhérent est dans cette table, puisqu'elle change (potentiellement) tous les ans.
Identifiant de l'adhésion [id PRIMARY KEY]
Identifiant BDE [idbde]
Année d'adhésion [annee]
Vient au WEI ou non [wei]
Identifiant de la transaction de paiement de cette adhésion [idtransaction]
Date d'adhésion [date]
Section [section]
Table aliases
Les correspondances entre les alias et les comptes.
Identifiant de l'alias [id PRIMARY KEY]
Identifiant BDE du compte correspondant [idbde]
Valeur de l'alias [alias]
Table historique
Les anciens pseudos des comptes.
Identifiant de l'ancien pseudo [id PRIMARY KEY]
Identifiant BDE du compte correspondant [idbde]
Pseudo qu'il avait avant [avant]
Nouveau pseudo [apres]
Timestamp du changement [date]
Est-ce que le pseudo avant est toujours une référence vers le compte en question ? [valide]
Table wei_1a
Les 1A qui se sont inscrit au WEI, contient les informations permettant de les répartir en équipes.
Nom [nom]
Prénom [prenom]
Genre [genre]
Adresse IRL [adresse]
Adresse mail [mail]
- …
Transactions
Table boutons
La liste des consos qu'on peut débiter.
Identifiant du bouton [id PRIMARY KEY]
Montant de la conso [montant] ( les montants sont stockés en centimes !)
Nom de la conso [label]
Catégorie de la conso [categorie]
Identifiant du bénéficiaire de la transaction [destinataire]
Une description détaillée du bouton [description]
Ce bouton doit-il être affiché [affiche DEFAULT true]
Table transactions
Une entrée pour chaque mouvement d'argent.
Identifiant de la transaction [id PRIMARY KEY]
Date de la transaction [date DEFAULT clock_timestamp()]
Type de la transaction [type \in {"transfert", "bouton", "don", "crédit", "retrait"}]
Identifiant de l'émetteur (celui qui paye) [emetteur]
Identifiant du destinataire (celui qui reçoit) [destinataire]
Quantité [quantite DEFAULT 1]
Montant unitaire [montant DEFAULT 0] ( les montants sont stockés en centimes !)
Description (coca, pinte, transfert d'argent (prima), …) [description]
Transaction valide ou non [valide]
Si cette transaction ne peut pas être dévalidée [cantinvalidate]
Table cheques
Une entrée pour chaque chèque fait au BDE (pour les crédits) ou émis par le BDE (pour les retraits).
Identifiant [id PRIMARY KEY]
Date de la transaction [date DEFAULT now()]
Nom de l'émetteur du chèque (NB : peut être différent de celui du compte crédité/retiré) [nom]
Prénom de l'émetteur du chèque [prenom]
Banque émettrice du chèque [banque]
Montant du chèque [montant] ( les montants sont stockés en centimes !)
Identifiant de la transaction correspondante (qui sera un crédit ou un retrait) [idtransaction]
Si c'est un retrait [retrait]
Si ça a été vérifié par le trésorier [checked]
Si il a été supprimé [deleted] (comme ça on ne supprime jamais vraiment un chèque)
Table virements
Une entrée pour chaque virement fait au BDE (pour les crédits) ou émis par le BDE (pour les retraits).
Identique à cheques.
Activités
Table activites
La liste des activités futures ou passées.
Identifiant de l'activité [id PRIMARY KEY]
Date de début [debut]
Date de fin (doit être supérieur à la date de début) [fin]
Nom de l'activité [titre]
Lieu où elle aura/a eu lieu [lieu]
Description de l'activité [description]
Identifiant du créateur de l'activité [responsable]
Organisateur(s) de l'activité [signature]
Identifiant de celui qui a validé l'activité [validepar DEFAULT -100]
Présence d'une liste d'invités [liste]
Si la liste a été imprimée [listeimprimee]
Si l'activité est en cours [en_cours]
Table invites
Une entrée par invité par activité.
Identifiant de l'invité [id PRIMARY KEY]
Nom de l'invité [nom]
Prénom de l'invité [prenom]
Identifiant de l'adhérent qui l'a invité [responsable]
Identifiant de l'activité à laquelle l'invité est invité [idact
Table entree_activites
Une entrée par personne entrée à une activité.
Identifiant de l'entrée [id PRIMARY KEY]
Date de l'entré [heure_entre]
Identifiant de l'activite [activite]
Si la personne est un invité [et_invite]
Identifiant du responsable si invité [responsable
Identifiant de la personne entrant sinon [idbde
Log
Table log
Enregistrement de ce qui se passe.
Des entrées sont ajoutées à cette table seulement quand une modification est faite.
Identifiant de l'évènement [id PRIMARY KEY]
Date de l'évènement [date DEFAULT now()]
IP du client qui a effectué la modification [ip (varchar)]
Utilisateur ayant effectué la modification [utilisateur]
La fonction qui a été appelée [fonction]
Ses éventuels paramètres [params DEFAULT '']
contient tel quel les paramètres passés à la commande, sauf pour une transaction, où on a "<idbde> (ne) consomme (pas) <quantite>*<description> (idbouton = <idbouton>) ([(over)forced used/needed])"
Configuration
Table configurations
Une ligne pour chaque set de valeurs de configuration. Dont un et un seul utilisé.
Cf plus bas
Intégrité
Comment maintenir la base cohérente.
La doc sur la cohérence sur le serveur
Un script/cron pourra lancer les vérifications à intervalle régulier.
Variables de configuration
Voici la liste des variables de configuration du serveur, leur signification et leur valeur dans la configuration par défaut. (On rappelle que les prix sont en centimes.)
On parle ici des variables qui sont stockées dans la table configurations de la base de données et qui sont susceptibles d'être modifiées on the fly (genre le prix du WEI, …).
La table contient également un champ id (PRIMARY KEY) et un champ nom pour référencer le set de paramètres ainsi qu'un champ used pour dire si c'est la configuration actuellement utilisée.
Nom du champ |
Valeur par défaut |
Signification |
prix_wei_normalien |
16500 |
prix de l'inscription incluant le WEI |
prix_wei_non_normalien |
9500 |
idem, pour les non-normaliens |
prix_adhesion |
4000 |
prix de l'adhésion sans WEI |
solde_negatif |
0 |
solde en dessous duquel on est en négatif (invitations et don bloqués, ...) |
solde_tres_negatif |
-1000 |
solde en dessous duquel le droit forced est nécessaire |
solde_pas_plus_negatif |
-5000 |
solde en dessous duquel le droit overforced est nécessaire |
start_next_year_month |
8 |
mois de la date à partir de laquelle une adhésion vaut pour l'année suivante |
start_next_year_day |
1 |
idem, mais le jour |
end_previous_year_month |
10 |
mois de la date après laquelle un compte n'est plus utilisable sans réadhésion |
end_previous_year_day |
1 |
idem, mais le jour |
year_boot_month |
9 |
mois du début de l'année scolaire |
year_boot_day |
1 |
idem, mais le jour |
historique_pseudo_timeout |
365 |
durée (en jours) avant qu'un ancien pseudo ne référence plus l'adhérent |
historique_incompressible |
24*14 |
durée (en heures) pendant laquelle on ne peut pas prendre l'ancien pseudo de quelqu'un |
listes_invites_opening_time |
672 |
durée (en heures) à partir de laquelle une liste d'invités est ouverte (avant l'activité, si elle est avec liste) |
listes_invites_closing_time |
1 |
durée (en heures) à partir de laquelle une liste d'invités est fermée (avant l'activité, si elle est avec liste) |
max_invitation_par_personne |
3 |
nombre maximum de personnes qu'un adhérent peut inviter à un pot |
max_invitation_par_an |
5 |
nombre maximum de fois où une personne peut être invitée à un pot (par an) |
toggle_transaction_timeout |
604800 |
durée (en secondes) au bout de laquelle une transaction ne peut plus être validée/dévalidée sans être admin (= une semaine) |
token_regenerate_password_delay |
259200 |
durée (en secondes) pendant laquelle un token de régénération de mot de passe est utilisable |
solde_mail_passage_negatif |
0 |
solde qui déclenche un envoi de mail à l'adhérent au moment où il passe en dessous |
prix_adhesion_late |
1500 |
prix de l'adhésion pendant la seconde partie de l'année (qui se termine le start_next_year_day/month) |
start_cheaper_adh_month |
3 |
mois à partir duquel l'adhésion est moins chère |
start_cheaper_adh_day |
1 |
idem, mais le jour |