Pourquoi TOMUSS n'utilise pas une BD relationnelle ?

Plutôt que de répondre à chaque fois oralement, voici quelques mots pour expliquer mon point de vue.

Une base de donnée doit obligatoirement être utilisée quand :

• Les données sont utilisées par d'autres applications.
• Plusieurs processus ou tâches modifient les données.
• Les données sont volumineuses.
• Les données ont une structure complexe.
• Les données sont souvent modifiées
• Les requêtes d'accès sont complexes.
• Les actions peuvent modifier plusieurs informations simultanément de manière cohérente.
• Le stockage est déporté.
• Des contraintes d'intégrité doivent être garanties même si l'application est buggée.

La très grande majorité des applications ont une de ces conditions réalisées et doivent donc impérativement utiliser une base de donnée.

Dans le cas de TOMUSS, aucune de ces conditions n'est présente. En conséquence, on peut se demander pourquoi utiliser une base de donnée alors que le surcoût est important en CPU, place mémoire, place disque, administration, configuration et que les avantages sont faibles ?

Dans le cas de TOMUSS on a besoin :

• d'un enregistrement instantané et fiable.
• d'une trace de toutes les modifications faites.
• de stocker des informations sémantiques et non des valeurs. Cela veut dire que l'on stocke des actions au lieu de données.
• de pouvoir facilement trouver l'origine des problèmes.

La solution à ces contraintes est simple : il faut un journal contenant les actions faites par l'utilisateur.

• La lecture du journal recrée la donnée en mémoire.
• Aucune modification ne peut perdre d'information, car seul des ajouts sont faits dans les fichiers.
• Le programmeur n'a qu'à lire le fichier pour avoir l'historique de la donnée, pas besoin d'outils supplémentaires.
• Dans le cas de TOMUSS il y a un journal (donc fichier) pour chaque Semestre/UE.
• Le stockage sous forme de journal permet des sauvegardes performantes.
  Au 14/01/2016 l'espace disque utilisé par TOMUSS contenant toutes les informations depuis 2008 occupait 2.3Go, outre les UE il contient les données associées aux enseignants et étudiants. Les 1690 sauvegardes journalières des données TOMUSS sont faites avec GIT et occupent 815Mo
• Si de plus le journal est au format JSON il peut directement être utilisé dans un navigateur web sans transformation. (cela n'a pas été fait dans TOMUSS, cela permettrait à l'utilisateur d'avoir une barre d'ascenseur pour voyager dans le temps)
• Le journal permet de synchroniser facilement les données entre un serveur et un client web : il suffit d'envoyer la partie du journal qui manque au client.

J'ai essayé de stocker les données TOMUSS dans une base relationnelle mais les performances étaient tellement mauvaises que j'ai abandonné. Il serait intéressant de réessayer avec une base de donnée comme Google HyperTable qui se rapproche plus des besoins de TOMUSS qu'une base de donnée relationnelle.

Pour ne pas pêcher par omission, voici les inconvénients liés au fait de ne pas avoir une base de donnée relationnelle dans le cas de TOMUSS :

• Il doit gérer un index des étudiants
• Les statistiques globales prennent de longues minutes, mais ce genre d'action est lancé une fois par an et seulement par l'administrateur.
• Les actions longues qu'il est nécessaire de faire chaque jour sont faites de nuit et donc le temps mis n'a pas beaucoup d'importance.
• Les actions les plus longues pour l'utilisateur sont certaines statistiques multi-semestrielles qui prennent une minute pour les grosses UE, mais les rares utilisateurs qui les utilisent le font une fois pas an.

La morale est qu'il ne faut pas dire :

• « Il ne faut jamais faire cela. »
• ni « Il faut toujours faire cela. »

car il existe toujours des contre-exemples.

Sauf :-) (car il y a forcément des contre-exemples) :

• Il ne doit jamais y avoir de redondance dans un code source
• Il faut toujours faire des sauvegardes.