Discussion :

[Hind4Dev]

Bonjours; je compte commencer un projet qui gère une base de données d'étudiants, la base doit être renouvelée chaque année, qui veut dire, chaque début d'année scolaire, j'ai besoin d'archiver l'ancienne base, les étudiants qui continuent leur scolarité je les fais passer donc le fait de créer une nouvelle base avec la même structure sinon juste les tables nécessaires (comme la table étudiant, notation ... ) et celà pour éviter d'avoir une seule table pour toutes les années (ça deviendra de plus en plus lourd pour rien)

alors j'ai besoin de comprendre comment on gère ce genre de bases (comme les bases de données universitaires, écoliers ...) car l'état des étudiants change chaque année (on a des étudiants qui partent d'autres qui restent, d'autres qui passent ...)

si vous avez des cours sur l'archivage des données et les modèles de structuration de ce genre de projet, je vous en serai très reconnaissante.

merci

[StringBuilder]

Plusieurs solutions, plus ou moins propres :
1/ Faire un backup, puis recréer la base
2/ Créer une base par année
3/ Créer un schéma par année
4/ Créer un jeu de table par année (en suffixant le nom des tables par exemple)
5/ En ajoutant un flag aux données inactives (booléen, année scolaire, etc.)

1 : Le plus simple, le plus performant. En revanche, impossible de consulter l'historique sans traitement lourd (restauration de base, etc.), pas de consolidation des données à des fins de statistiques par exemple (évolution du nombre d'élèves sur les 10 dernières années par exemple)

2 et 3 : Solution moins radicales que la première. Restent performantes même si les données au final s'accumulent sur le serveur. Certaine complexité pour le requêtage des données historisées.

4 : A éviter absolument.

5 : A utiliser absolument. En effet, les données "inactives" ne seront de toute façon pas chargées en mémoire puisque jamais utilisées. En revanche, l'écriture d'une requête permettant de travailler aussi sur l'historique se fera naturellement, en modifiant simplement un critère de filtre.

A mon sens, les données 1 à 3 ne doivent être utilisées que dans les systèmes qui gèrent un nombre immense de données dont les informations unitaires n'ont aucun intérêt à être archivées. Il faudra toujours coupler ces données à une base de données d'analyses contenant des données agrégées.

Par exemple, dans une centrale nucléaire, il y a des milliers de capteurs qui font des relevés plusieurs fois par seconde.
Mais la détection d'un incident ne porte que sur les quelques dernières minutes/heures de relevés. Donc passé un délai assez court (quelques heures, jours), on peut tout à fait supprimer les données anciennes.
En revanche, il est intéressant de détecter qu'en 20 ans la température des eaux rejetées par le système de refroidissement a augmenté de 1 °C, et il faut pouvoir savoir si ça s'est fait au rythme de 0,05 °C par an, imputable éventuellement à la hausse de température de l'eau en entrée du système, ou si on a pris les 1 °C au court des 6 derniers mois (signe d'une usure anormale ou d'une micro-fissure par exemple).

Avant de supprimer le détail des données, on va donc systématiquement consolider (agréger sur des période, unifier plusieurs mesures de captures en une seule valeur, etc.) afin de pouvoir analyser aussi finement que possible les données sans devoir conserver tout l'historique.

Dans ton cas, on aura dans ce type de base annexe :
- le nombre d'étudiants selon plusieurs critères (age, sexe, classe, matières, trimestre, etc.)
- la moyenne générale selon plusieurs critères (idem)
Sans pour autant conserver tous les noms et prénoms ni tous les relevés de notes.

Si tu ne veux pas faire ce genre de base annexe, alors seule la solution 5 est à retenir. Mise à part si tu stockes toutes les notes de tous les élèves de toutes les écoles de France, tu ne devrais jamais rencontrer la moindre limitation en raison du volume des données. On parle tout au plus de quelques centaines de milliers de lignes visiblement (ce qui représente déjà un sacré périmètre).

[Hind4Dev]

merci pour ces indications et précisions, en faite mon projet concerne une seule école et non pas toutes les écoles du pays, donc le nombre est limité en approximation, je dis plutôt la solution 1 me convient seulement le backup n'a pas besoin d'être forcément archivé pour qu'il puisse être consulté facilement si je change de période pour pouvoir consulter une données ancienne (j'ai vu ça dans une application)

[escartefigue]

Plusieurs solutions, plus ou moins propres :
1/ Faire un backup, puis recréer la base
2/ Créer une base par année
3/ Créer un schéma par année
4/ Créer un jeu de table par année (en suffixant le nom des tables par exemple)
5/ En ajoutant un flag aux données inactives (booléen, année scolaire, etc.)

Et aussi et de préférence, car beaucoup plus simple :
6/ partitionner la (les) table(s) par année

Mais surtout, il me semble largement préférable de gérer une date de sortie de l'étudiant, et de prévoir un traitement de purge de certaines données correspondants aux étudiants sortis depuis plus de xx années
les solutions 1 à 4 sont à exclure : inutilement compliquées, elles nécessitent de recréer toutes les données des étudiants qui continuent leur cycle ou qui redoublent

Les anciens étudiants sont en droit de demander des copie de leurs résultats aux examens ou autres informations, bien longtemps après leur départ
Les enseignants souhaitent aussi consulter les résultats ou retrouver des supports de cours
etc...

il faudra donc à minima prévoir une base archive pour pouvoir répondre à ce type de besoins

[StringBuilder]

En effet, le partitionnement est une bonne alternative.

Déformé par SQL Server qui ne propose le partitionnement des données que sur la version Entreprise...

[CinePhil]

Comme mes prédécesseurs, je pense que pour une seule école, vous avez bien le temps de remplir votre BDD avant d'avoir des soucis de performance liés au volume de données stockées, si votre serveur est correctement dimensionné et si votre BDD est correctement modélisée et indexée.

Si toutefois vous voulez quand même archiver des données, il y a la solution consistant à créer des tables d'archive, ou un schéma d'archive et d'y déverser les données périmées chaque année pour ne conserver en production que les données actives de l'année en cours.

[Hind4Dev]

donc la meilleur solution est de prévoyer un schéma par année

[CinePhil]

donc la meilleur solution est de prévoyer un schéma par année

Non. On AJOUTE les données de l'année qu'on veut archiver dans le schéma d'archive.

Mais encore une fois, avant que vous ayez BESOIN d'archiver pour problèmes de performances, vous avez le temps.

[Hind4Dev]

donc je prévois une solution, est de numéroter les tables à archiver dès la création par année, et les tables intermédiaires qui n'ont pas besoin d'être archivées je les laisse (comme la tables des matières ou des filières ...)

[CinePhil]

Qu'entendez-vous par "numéroter les tables" ? Je ne vois pas l'intérêt.

Je vais prendre une petit exemple, pour être plus clair sur la solution éventuellement possible, même si, encore une fois, je ne pense pas que vous en ayez besoin.

Schéma de production

Règles de gestion :
1) Un étudiant suit un parcours de formation et un parcours de formation peut être suivi par plusieurs étudiants.

Exemple : L'étudiant Dupont suit le parcours de formation Master MEEF. Pour simplifier, je ne tiens pas compte du fait que le master MEEF est sur deux ans et que l'étudiant a déjà pu arriver dans l'école en licence.

MCD qui découle de la règle de gestion :
Etudiant -1,1----suivre----0,n- parcours-formation

Tables :
te_parcours_prc (prc_id, prc_code, prc_libelle...)
te_etudiant_etu (etu_id, etu_id_parcours, etu_nom, etu_annee_entree...)

Archivage
On souhaite archiver les étudiants qui ne sont plus dans l'établissement.
On crée dans un schéma d'archive de la même base de données une table pour les étudiants ayant le même modèle que la table de prod + une à plusieurs colonnes qui indiquent la date et/ou la raison de l'archivage :
te_etudiant_archive_eta (eta_id, eta_id_parcours_eta_nom, eta_annee_entree, eta_date_sortie, eta_motif...)

On peut ainsi avoir dans cette table d'archive tous les étudiants sortis de toutes les années passées et ne conserver dans la table de prod que les étudiants présents.

[Hind4Dev]

merci j'ai compris