C’est quand même plus simple de ne pas créer de doublon même si ça permet en effet de garder l’information sur la fréquence des mesures, par exemple...
Je suppose tu trouves ça plus simple parce que on fait tout dans un seul fichier de script ou bien avec la même ligne de cron.
Moi je trouve ça plus simple au niveau du partage des responsabilités. Le code source qu'il nous a montré a une responsabilité qui s'énonce simplement: Extraction des valeurs à intervalle régulier.
En input les capteurs, en output le fichier de log. C'est simple et sans surprise. Et ça rassure sur la fiabilité des données. Parce quand on a des données historiques, ce qu'on veut c'est que ça soit fiable et qu'il n'y ait pas des bugs qui se baladent. Les données polluées par des bugs sont irrémédiablement perdues.
Le fichier de log est trop gros? On compresse. C'est un problème super connu, il suffit de rgarder /var/log il est plein de .gz
Ensuite, on fait du filtrage ou de l'aggrégation avec des scripts séparés. On fait ça dans seconds temps, il y a de bonne chances pour qu'on crée régulièrement des nouveaux scripts et on ne sait pas à l'avance si des précédentes opérations de filtrage vont pas être dérengeantes.
Imagine qu'on veut afficher simplement les valeurs des la journée avec la granularité de temps la plus fine possible, le 1/4 d'heures. Le programmeur devra alourdir son script d'une logique de décompression pour récupérer les valeurs éjectées.
[^] # Re: Archivage des fichiers
Posté par j_m . En réponse au message Problème de doublons dans un fichier txt. Évalué à 3. Dernière modification le 13 août 2015 à 10:32.
Je suppose tu trouves ça plus simple parce que on fait tout dans un seul fichier de script ou bien avec la même ligne de cron.
Moi je trouve ça plus simple au niveau du partage des responsabilités. Le code source qu'il nous a montré a une responsabilité qui s'énonce simplement: Extraction des valeurs à intervalle régulier.
En input les capteurs, en output le fichier de log. C'est simple et sans surprise. Et ça rassure sur la fiabilité des données. Parce quand on a des données historiques, ce qu'on veut c'est que ça soit fiable et qu'il n'y ait pas des bugs qui se baladent. Les données polluées par des bugs sont irrémédiablement perdues.
Le fichier de log est trop gros? On compresse. C'est un problème super connu, il suffit de rgarder /var/log il est plein de .gz
Ensuite, on fait du filtrage ou de l'aggrégation avec des scripts séparés. On fait ça dans seconds temps, il y a de bonne chances pour qu'on crée régulièrement des nouveaux scripts et on ne sait pas à l'avance si des précédentes opérations de filtrage vont pas être dérengeantes.
Imagine qu'on veut afficher simplement les valeurs des la journée avec la granularité de temps la plus fine possible, le 1/4 d'heures. Le programmeur devra alourdir son script d'une logique de décompression pour récupérer les valeurs éjectées.