4 serveurs, 4 scripts (en comptant les commandes pour FTP), 3 langages !
Il faudrait en ajouter encore, pour être sûr que ça cafouille...
Sinon,
- Au niveau des serveurs :
Le serveur Windows et le serveur du SGBD sont des données de base.
À partir de là, on peut préférer faire le boulot sur le serveur Windows, sur le serveur de SGBD ou sur une machine dédiée qui se connecte aux deux. Pas de raison d'en ajouter plus.
- Au niveau des opérations :
Il y a la récupération des fichiers, leur traitement pour obtenir le code SQL à injecter dans la base, et son injection dans la base.
- Au niveau de l'accès aux fichiers :
Si l'on travaille à partir du serveur Windows (après tout, Perl comme PHP et peut-être même expect existent sous Windows), l'accès est direct; mais il faut par contre disposer d'un module d'accès à la base.
Si l'on travaille à partir d'une autre machine, il faut alors accéder aux fichiers à distance; le plus simple pour ça est d'exporter le répertoire depuis Windows (c'est déjà dedans, alors pourquoi ajouter un serveur FTP ou autre) et d'y accéder directement depuis le script de traitement avec smbmount (et smbumount en fin de script).
- Au niveau des traitements :
expect est une commande basée sur le langage Tcl (note : il existe l'équivalent en module pour Perl), permettant de faire des scripts interagissant avec des commandes qui attendent une entrée interactive. On n'est pas dans ce cas (l'injection de SQL dans une base peut se faire directement depuis Perl, PHP ou d'autres langages avec le module approprié, sans utiliser la commande interactive) et les expressions régulières de Perl suffisent amplement à analyser un format CSV. Donc pas de raison d'utiliser expect.
Pas besoin non plus de fusionner les fichiers, autant les ouvrir directement depuis le script qui effectue le traitement (par exemple en bouclant sur un file globbing (en Perl while (</mnt/smb/*.log>) { open FILE, $_; ... close FILE}).
- Au niveau de l'injection dans la base : comme je l'ai dit, elle peut se faire directement depuis le script avec le module approprié.
Enfin bon, un seul script en Perl peut faire tout le boulot (sinon, ce serait triste pour Perl...). Donc deux ou trois serveurs, un script et un langage suffisent.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
# Pourquoi faire simple...
Posté par Arthur Accroc . En réponse au message script perl de récupération de fichiers. Évalué à 2.
Il faudrait en ajouter encore, pour être sûr que ça cafouille...
Sinon,
- Au niveau des serveurs :
Le serveur Windows et le serveur du SGBD sont des données de base.
À partir de là, on peut préférer faire le boulot sur le serveur Windows, sur le serveur de SGBD ou sur une machine dédiée qui se connecte aux deux. Pas de raison d'en ajouter plus.
- Au niveau des opérations :
Il y a la récupération des fichiers, leur traitement pour obtenir le code SQL à injecter dans la base, et son injection dans la base.
- Au niveau de l'accès aux fichiers :
Si l'on travaille à partir du serveur Windows (après tout, Perl comme PHP et peut-être même expect existent sous Windows), l'accès est direct; mais il faut par contre disposer d'un module d'accès à la base.
Si l'on travaille à partir d'une autre machine, il faut alors accéder aux fichiers à distance; le plus simple pour ça est d'exporter le répertoire depuis Windows (c'est déjà dedans, alors pourquoi ajouter un serveur FTP ou autre) et d'y accéder directement depuis le script de traitement avec smbmount (et smbumount en fin de script).
- Au niveau des traitements :
expect est une commande basée sur le langage Tcl (note : il existe l'équivalent en module pour Perl), permettant de faire des scripts interagissant avec des commandes qui attendent une entrée interactive. On n'est pas dans ce cas (l'injection de SQL dans une base peut se faire directement depuis Perl, PHP ou d'autres langages avec le module approprié, sans utiliser la commande interactive) et les expressions régulières de Perl suffisent amplement à analyser un format CSV. Donc pas de raison d'utiliser expect.
Pas besoin non plus de fusionner les fichiers, autant les ouvrir directement depuis le script qui effectue le traitement (par exemple en bouclant sur un file globbing (en Perl while (</mnt/smb/*.log>) { open FILE, $_; ... close FILE}).
- Au niveau de l'injection dans la base : comme je l'ai dit, elle peut se faire directement depuis le script avec le module approprié.
Enfin bon, un seul script en Perl peut faire tout le boulot (sinon, ce serait triste pour Perl...). Donc deux ou trois serveurs, un script et un langage suffisent.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone