Discussion :

[humitake]

Bonjour,

Je suis actuellement en train de travailler sur un système d'historisation de données.
La façon dont est construit la solution me laisse 2 solutions :

• Utiliser le programme C++ qui alimente la base et ajouter une comparaison de données pour générer l'historique.
• Utiliser un trigger qui génère l'historique pour chaque nouvelle données inséré.

Pour simplifier j'ai en gros 2 algo :

1. Récupération de tous les défauts actuellement en base
2. Début de transaction (BEGIN)
3. Suppression de tous les défauts en base
4. Scan de tous le systèmes
5. Ajouts des défauts en base
6. Comparaison des défauts précédemment récupéré (étape 1) et ceux qui viennent d'être récupérés
7. Mise à jour de l'historique
8. Fin de transaction (COMMIT)

Ou

1. Début de transaction (BEGIN)
2. Suppression de tous les défaut en base
3. Scan de tous le systèmes
4. Ajouts des défauts en base
5. Fin de transaction (COMMIT)
6. Lancement des triggers qui mettent à jour la BDD pour générer l'historique

De mon point de vue la 2ème solution surtout pour les deux points suivant :

• On garde la gestion de données en interne dans la base, mise à part pour l'insertion (mais la pas le choix)
• Ca évite de toucher le programme qui se charge de la récupération des données

Mais quand est-il au niveau des performances ? Ou d'autre paramètre que je n'aurai pas en tête ?

Bon Week-end

[skuatamad]

Je ne comprends pas ce que sont les défauts et donc la succession des opérations, mais j'apporte juste une correction sur la partie trigger.

5. Fin de transaction (COMMIT)
6. Lancement des triggers qui mettent à jour la BDD pour générer l'historique

Cet enchainement est faux, les triggers font partie de la transaction.
En mysql, il n'y a que des triggers for each row donc pour chaque ligne insérée le trigger sera exécuté.

Les triggers sont souvent utilisés pour gérer de l'historique.
Consernant les perfs, ils pénalisent effectivement les chargements en masse de part leur exécution ligne à ligne.

[humitake]

Les défauts sont des informations récupérés sur des automates qui doivent être surveillé à distance.

Cet enchainement est faux, les triggers font partie de la transaction.

Au temps pour moi, merci pour la précision.

Les triggers sont souvent utilisés pour gérer de l'historique.
Consernant les perfs, ils pénalisent effectivement les chargements en masse de part leur exécution ligne à ligne.

Dans mon cas ce n'est pas du chargement en masse, dans le pire des cas ce serai une centaine de ligne d'un coup.
Je vais donc opter pour la solution des triggers.

Merci pour les infos !