Le 26 mars 2013 17:21, Bzzz <lazyvi...@gmx.com> a écrit : > On Tue, 26 Mar 2013 17:09:15 +0100 > Gabriel Euzet <geu...@sqli.com> wrote: > > > Par contre, comme je l'ai dit plus tôt : pas de connexion permanente > > avec le site client. > > Pourquoi? Ça n'est pa le volume de données qui va boucher > le tuyau… >
Le client héberge des données médicales. Il recherche le maximum de sécurité. Une porte d'entrée ouverte en moins ! > > > certains de nos clients ont un service > > informatique et l'exigeront. Tout ça me donne l'impression que la > > solution va relever de la bricole :-/ > > Pas spécialement, tu peux tout à fait lancer un script avec > un cron qui effectuera une requête sur la DB du client > (peut-être en effectuant une sélection des données pour > obtenir une fréquence de mesure inférieure à la sienne), > qui exportera les résultats en CSV et qui t'expédiera le > paquet une fois compressé. > > Sauf que ta BAL devra être capable de recevoir "une certaine > taille" d'e-mails pour que ça passe (dépendante de la Qté de > données à transmettre). > > Et de ton côté, tu peux tout à fait exécuter le script inverse, > qui viendra récupérer l'attachment, le décompressera et > l'insérera dans ta propre DB. > > Mais, encore une fois, c'est une moins bonne solution que de > recevoir les données au fil des mesures. > mail ou FTP, le second serait mon préféré car plus facile à automatiser à la réception. Mais l'idée est là et c'est cela que je sous-entendais par bricole. Je voulais dire qqch qui n'existe pas en natif. Ta solution a le mérite de rester simple. Restera à trouver comment restaurer les données sur un système qui hébergera N (jusqu'à 50) sites équivalents. Zabbix propose la notion de groupe. Peut-être pourra-t-on affecter un groupe lors de la restauration. Merci pour tes éclaircissements :-)
