Discussion :

[forstera]

Bonjour à tous,

Je développe depuis maintenant plus de 2 ans un outils scolaire de gestion de pensums comprenant tous les enseignants mais également toutes les tâches hors enseignement (administratives) et les remplacements.
Ma base de donnée HFSQL est relativement conséquente (cf schéma ci-dessous) et je suis confronté aujourd'hui à un problème pratique que je ne sais pas encore trop comment aborder :

Le système est conçu pour pouvoir travailler sur plusieurs années scolaires. En effet, lorsque l'utilisateur crée une nouvelle volée d'études, les cours sont générés pour l'ensemble de la durée d'études (cela dépend des filières mais en règle général 4 ans). De cette manière, lorsqu'il attribue un enseignant à un cours dans une classe donnée, ce dernier sera 'occupé' dans cette classe durant toutes les années de formations. Cela permet d'avoir des calculs prévisionnels de charge pour les enseignants pour les x prochaines années.
A cela s'ajoute les mandats administratifs, les remplacements, etc ...


La personne en charge de l'attribution de ces pensums m'indique que pour une nouvelle volée, elle tâtonne parfois plusieurs semaines avant de trouver le bon équilibre pour chacun (je passe les détails). Et aimerait donc avoir un peu un mode bac à sable pour revenir en arrière si elle constate que le chemin pris n'est pas le bon dans l'attribution des cours. Nous avions d'abord pensé à lui permettre de faire des sauvegardes de la base de données et rappeler des ancienne versions si nécessaire. Cela serait pertinent si j'avais une base de données par année mais dans mon cas, j'ai d'un côté la vie scolaire qui continue avec des changements permanents (remplacements) et d'un autre côté le responsable qui veut faire des tests et pouvoir revenir en arrière.
Cela me semblerait très hasardeux vue la complexité de ma base et les interactions entre les tables de me lancer dans la mise en place d'un serveur de test dans lequel il pourrait faire ses tests et, lorsque sa nouvelle volée est validée, récupérer toutes ses données et les insérer dans notre base de prod.
Qu'en pensez-vous ?
Merci pour vos idées et commentaires
Arnaud

[tbc92]

J'imagine que la liste des tables concernées par cela est relativement limitée , disons : table1, table2, table3 et table4.

Je créerais 4 nouvelles tables table1bis, table2bis, table3bis et table4bis.
Dans ces 4 tables, j'ajouterais une colonne IDScenario.
Et j'ajouterais une toute petite table avec 2 colonnes : IDScenario , NomScenario plus éventuellement une date par exemple.

Quand l'utilisateur 'choisit de créer un nouveau scénario (une simulation, un test), tout ce qui concerne ce scénario a donc un identifiant unique (et donc il faut des clés composées partout, où on ajoute cet IDScénario, en plus des clés nécessaires.

Et il y a un outil quelque part pour copier un scénario au choix de (table1bis, table2bis, table3bis et table4bis) vers (table1, table2, table3 et table4).

[frenchsting]

Bonjour,

Je me lance, mais c'est pas simple, au vu du nombre de tables de ta base.

0. Un nombre très limité d'utilisateurs doit avoir accès à cette fonctionnalité.
1. Créer une base test/bac à sable. Il faut que ton espace disque te le permette.
2. Lors d'uns demande de crash test, copier la base de prod vers la base de test.
3. Identifier les tables liées à la volée d'études qui ont été modifiées. Attention : les tables modifiées dans la base de test et pas les différences entre base de prod et base test. Si des modif sont faites en prod pendant le crash test, on aurait une différence erronée
4. Copier les nouveaux enregistrements de la base de test vers la base de prod. Je te conseille d'utiliser les transactions.

Idée bonus : je ne connais pas les mécanismes que tu utilises pour créer une volée d'études, mais le détail plus serait de restreindre la base test aux seules tables concernées et garder la connexion aux tables "fixes" sur la base de prod.

Autre chose : utiliser des transactions pour cette copie.

[forstera]

Merci à vous pour vos idées ..
C'est effectivement dans les voies que vous indiquez que je pense me diriger.
J'avas espéré que les tables hfsql possédaient des champs automatiques tels que date création et date de modification mais ce n'est pas le cas.

Vous avez raison, cette fonctionnalité ne devrait être utilisée que par 1 seule personne.

J'arrive assez bien à définir les tables modifiées pour la création d'une volée d'études mais le problème est que ces tables peuvent être modifiées tant en prod qu'en test et comme j'ai mes mes clés primaires dans ces tables à indexation automatique je penser que je devrais changer cela et travailler avec des clés composées je suppose.
Merci à vous, je creuse encore le sujet.

[Voroltinquo]

Bonjour,
Sacré drap de lit (si tu l'imprimes)
Pour éviter cela, la plupart des outils mettent à la disposition de l'analyste la notion de package. (Dossier perso sous l'EDI WINDEV) cela permet de regrouper les tables, les requêtes etc en fonction de l'organisation du projet (e.g. PACK_Stratif,) chaque package pouvant comporter des sous packages.

En ce qui concerne ton problème.
La première chose à faire est de mettre à plat ce que tu désires et dans ton MCT/MPT, traduire cela en opération/actions qui seront détaillées au fur et à mesure.
Ton package pensum pourra être géré via HChangeRep. Chaque brouillon pourra par exemple être géré dans un Rep (...\Promon\Brouillonm)

[frenchsting]

J'arrive assez bien à définir les tables modifiées pour la création d'une volée d'études mais le problème est que ces tables peuvent être modifiées tant en prod qu'en test et comme j'ai mes mes clés primaires dans ces tables à indexation automatique je penser que je devrais changer cela et travailler avec des clés composées je suppose.
Merci à vous, je creuse encore le sujet.

Pour le souci des IdAuto, ce n'en est pas vraiment un. Lorsque tu vas ajouter un enregistrement dans la table de prod, il "suffit" que tu mémorises le nouvel id et que tu le changes dans les clés étrangères des tables ciblées. Le plus important est de bien définir l'ordre des tables pour l'ajout.

[JeAn-PhI]

bonjour,

est ce que passer par des vues (matérialisée ou non) ne seraient pas envisageable ?

[forstera]

Bonjour à tous et merci pour vos idées et vos pistes ; il faudra que j'explore tout cela....
Les packages semblent une piste intéressante que je ne connais pas du tout ...

C'est vrai que les numéros auto peuvent être contournés car si je copie une partie des données de ma base de test vers celle de prod, de nouveaux ID seront générés ; à ma charge ensuite de les récupérer pour recréer les liens avec les données liées ...

Il faut maintenant que je planche là-dessus avec toutes vos idées crée un concept.
Merci à vous tous

[kunnskap]

HFSQL dispose de champs horodatages pour renseigner automatiquement la date et l'heure de création/modification.
Après perso, pas du tout fan des solutions a base de sauvegardes/restauration/duplication/joujou avec les tables
Ca finit souvent en "ET ZUT JE ME SUIS TROMPE"
Ce use case devrait selon moi être inclus dans le modèle. Donc dans les tables qui sont mises en jeu, prévoir qu'un scénario puisse être dupliqué à titre de sauvegarde et entièrement supprimé si besoin via son ID. Et pouvoir tagger via un booléen le fait que ce scénario est "en essai" et que c'est voué à changer. Si on veut revenir sur une version antérieure, le user pourrait choisir parmi les scénarios taggés "en essai": les scénarios suivants sont supprimés (ca nécessite de gérer une "session" d'essais pour pas supprimer les scénarios du collègue d'en face bien sur, ça se conçoit)
Si a chaque étape il faut sauvegarder c'est un peu lourd mais je ne connais pas assez la fréquence des changements pour me prononcer (c'est surement ce qui se trouve dans le "je passe les détails" )