[WD75] Executer une procedure avec des paramètres en dynamique
2 réponses
Roumegou Eric
Bonjour,
Je me casse la tête depuis un moment sur ce pb.
J'ai un programme qui gère les imports de fichiers dans des tables.
Tout est paramétrable. On saisit une table de correspondance entre les
zones fichiers et les colonnes de la table, cela lit le fichier et crée
un script sql qui est ensuite lancé.
Une colonne de la table cible peut être initiée par une (ou plusieurs)
zones du fichier source, par une constante, par une fonction. Ce
dernier cas est ce que j'appelle une zone calculée. Cela utilise des fn
WD qui recoivent des paramètres (une ou des zones du fichiers, des
constantes) et retourne une valeur.
Tout ça est mémorisé. Là où ça se corse, c'est pour le script sql.
Ok pour les zones fichiers et les constantes mais pour les zones
calculées se pose le pb suivant.
je pourrais utiliser la compilation dynamique. J'ai dans mes variables
le code déjà préparé
ex PPL_CAT1=MAFONCTION1(DEP)
ou PPL_CAT2=MAFONCTION2(ZONE2,"MACONSTANTE")
mais je crains que cela ne soit trop lourd en temps de traitement. Si
j'importe 5000 lignes, je ferais 5000 fois cette compil dynamique et
cela pour chaque zone calculée.
Autre possibilité : rechercher mes parametres et les remplacer par leur
valeur courante (corresp zone fichier) ou les constantes et passer le
tout en Un seul param à mes fn. Puis redécouper ensuite la chaine dans
la fn. (mais je trouve ça ch..)
Avez vous des idées là dessus ??
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel
Bonsoir, Roumegou Eric writes:
Bonjour,
Je me casse la tête depuis un moment sur ce pb.
J'ai un programme qui gère les imports de fichiers dans des tables. Tout est paramétrable. On saisit une table de correspondance entre les zones fichiers et les colonnes de la table, cela lit le fichier et crée un script sql qui est ensuite lancé. Une colonne de la table cible peut être initiée par une (ou plusieurs) zones du fichier source, par une constante, par une fonction. Ce dernier cas est ce que j'appelle une zone calculée. Cela utilise des fn WD qui recoivent des paramètres (une ou des zones du fichiers, des constantes) et retourne une valeur.
Tout ça est mémorisé. Là où ça se corse, c'est pour le script sql. Ok pour les zones fichiers et les constantes mais pour les zones calculées se pose le pb suivant.
je pourrais utiliser la compilation dynamique. J'ai dans mes variables le code déjà préparé ex PPL_CAT1=MAFONCTION1(DEP) ou PPL_CAT2=MAFONCTION2(ZONE2,"MACONSTANTE")
mais je crains que cela ne soit trop lourd en temps de traitement. Si j'importe 5000 lignes, je ferais 5000 fois cette compil dynamique et cela pour chaque zone calculée.
Autre possibilité : rechercher mes parametres et les remplacer par leur valeur courante (corresp zone fichier) ou les constantes et passer le tout en Un seul param à mes fn. Puis redécouper ensuite la chaine dans la fn. (mais je trouve ça ch..)
Avez vous des idées là dessus ??
Tout dépend de la volumétrie, et de la complexité de la fonction. C'est discutable, et il est évident que ce qui va s'appliquer sur 5000 lignes et qui est acceptable en terme de temps le sera moins sur 1 million de lignes.
A titre d'exemple, j'avais fait une "moulinette" qui devais extraire 100 000 lignes d'une table sous Mysql et surtout reprendre le contenu d'un longtext pour le recréer des tables et colonnes, le résultat final était une table avec quelques millions de lignes.
J'avais 2 solutions. La première était de lire chaque ligne avec un sqlsuivant faire appliquer ma fonction sous windev et écrire dans la nouvelle table
La seconde était de découper ma fonction windev, en fonction élémentaire SQL, et décrire dans des tables mysql temporaires, avec création des index à la fin des écritures dans les tables...
Dans le premier cas c'était vraiment plus simple. L'inconvénient était la charge réseau induite (lecture/ecriture), et surtout le temps.
Dans le second cas, l'inconvénient c'était plus la complexité pour tr ouver la solution (principe des tables temporaires, trouver les bonnes fonctions...).L'avantage charge réseau quasi nulle, elle était liée uniquement au test du type count, et de l'envoi des mysqlexec.
Dans le premier cas 24 heures pour faire la conversion, dans le second cas moins d'une 1/2 HEURE.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Bonsoir,
Roumegou Eric <UtilisezleLien@fin.msg> writes:
Bonjour,
Je me casse la tête depuis un moment sur ce pb.
J'ai un programme qui gère les imports de fichiers dans des
tables. Tout est paramétrable. On saisit une table de correspondance
entre les zones fichiers et les colonnes de la table, cela lit le
fichier et crée un script sql qui est ensuite lancé.
Une colonne de la table cible peut être initiée par une (ou plusieurs)
zones du fichier source, par une constante, par une fonction. Ce
dernier cas est ce que j'appelle une zone calculée. Cela utilise des
fn WD qui recoivent des paramètres (une ou des zones du fichiers, des
constantes) et retourne une valeur.
Tout ça est mémorisé. Là où ça se corse, c'est pour le script sql.
Ok pour les zones fichiers et les constantes mais pour les zones
calculées se pose le pb suivant.
je pourrais utiliser la compilation dynamique. J'ai dans mes variables
le code déjà préparé
ex PPL_CAT1=MAFONCTION1(DEP)
ou PPL_CAT2=MAFONCTION2(ZONE2,"MACONSTANTE")
mais je crains que cela ne soit trop lourd en temps de traitement. Si
j'importe 5000 lignes, je ferais 5000 fois cette compil dynamique et
cela pour chaque zone calculée.
Autre possibilité : rechercher mes parametres et les remplacer par
leur valeur courante (corresp zone fichier) ou les constantes et
passer le tout en Un seul param à mes fn. Puis redécouper ensuite la
chaine dans la fn. (mais je trouve ça ch..)
Avez vous des idées là dessus ??
Tout dépend de la volumétrie, et de la complexité de la
fonction. C'est discutable, et il est évident que ce qui va
s'appliquer sur 5000 lignes et qui est acceptable en terme de temps le
sera moins sur 1 million de lignes.
A titre d'exemple, j'avais fait une "moulinette" qui devais extraire
100 000 lignes d'une table sous Mysql et surtout reprendre le contenu
d'un longtext pour le recréer des tables et colonnes, le résultat
final était une table avec quelques millions de lignes.
J'avais 2 solutions.
La première était de lire chaque ligne avec un sqlsuivant faire
appliquer ma fonction sous windev et écrire dans la nouvelle table
La seconde était de découper ma fonction windev, en fonction
élémentaire SQL, et décrire dans des tables mysql temporaires, avec
création des index à la fin des écritures dans les tables...
Dans le premier cas c'était vraiment plus simple. L'inconvénient était
la charge réseau induite (lecture/ecriture), et surtout le temps.
Dans le second cas, l'inconvénient c'était plus la complexité pour tr ouver la
solution (principe des tables temporaires, trouver les bonnes
fonctions...).L'avantage charge réseau quasi nulle, elle était liée
uniquement au test du type count, et de l'envoi des mysqlexec.
Dans le premier cas 24 heures pour faire la conversion, dans le second
cas moins d'une 1/2 HEURE.
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
J'ai un programme qui gère les imports de fichiers dans des tables. Tout est paramétrable. On saisit une table de correspondance entre les zones fichiers et les colonnes de la table, cela lit le fichier et crée un script sql qui est ensuite lancé. Une colonne de la table cible peut être initiée par une (ou plusieurs) zones du fichier source, par une constante, par une fonction. Ce dernier cas est ce que j'appelle une zone calculée. Cela utilise des fn WD qui recoivent des paramètres (une ou des zones du fichiers, des constantes) et retourne une valeur.
Tout ça est mémorisé. Là où ça se corse, c'est pour le script sql. Ok pour les zones fichiers et les constantes mais pour les zones calculées se pose le pb suivant.
je pourrais utiliser la compilation dynamique. J'ai dans mes variables le code déjà préparé ex PPL_CAT1=MAFONCTION1(DEP) ou PPL_CAT2=MAFONCTION2(ZONE2,"MACONSTANTE")
mais je crains que cela ne soit trop lourd en temps de traitement. Si j'importe 5000 lignes, je ferais 5000 fois cette compil dynamique et cela pour chaque zone calculée.
Autre possibilité : rechercher mes parametres et les remplacer par leur valeur courante (corresp zone fichier) ou les constantes et passer le tout en Un seul param à mes fn. Puis redécouper ensuite la chaine dans la fn. (mais je trouve ça ch..)
Avez vous des idées là dessus ??
Tout dépend de la volumétrie, et de la complexité de la fonction. C'est discutable, et il est évident que ce qui va s'appliquer sur 5000 lignes et qui est acceptable en terme de temps le sera moins sur 1 million de lignes.
A titre d'exemple, j'avais fait une "moulinette" qui devais extraire 100 000 lignes d'une table sous Mysql et surtout reprendre le contenu d'un longtext pour le recréer des tables et colonnes, le résultat final était une table avec quelques millions de lignes.
J'avais 2 solutions. La première était de lire chaque ligne avec un sqlsuivant faire appliquer ma fonction sous windev et écrire dans la nouvelle table
La seconde était de découper ma fonction windev, en fonction élémentaire SQL, et décrire dans des tables mysql temporaires, avec création des index à la fin des écritures dans les tables...
Dans le premier cas c'était vraiment plus simple. L'inconvénient était la charge réseau induite (lecture/ecriture), et surtout le temps.
Dans le second cas, l'inconvénient c'était plus la complexité pour tr ouver la solution (principe des tables temporaires, trouver les bonnes fonctions...).L'avantage charge réseau quasi nulle, elle était liée uniquement au test du type count, et de l'envoi des mysqlexec.
Dans le premier cas 24 heures pour faire la conversion, dans le second cas moins d'une 1/2 HEURE.
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Roumegou Eric
Bonjour Merci de ta réponse,
Daniel a écrit :
Bonsoir, Tout dépend de la volumétrie, et de la complexité de la fonction. C'est discutable, et il est évident que ce qui va s'appliquer sur 5000 lignes et qui est acceptable en terme de temps le sera moins sur 1 million de lignes.
A titre d'exemple, j'avais fait une "moulinette" qui devais extraire 100 000 lignes d'une table sous Mysql et surtout reprendre le contenu d'un longtext pour le recréer des tables et colonnes, le résultat final était une table avec quelques millions de lignes.
C'est un peu cela mon pb. C'est un outil générique d'ETL sur mes bases. Donc à fortiori, je ne connaîs pas la volumétrie, ni la table concernée, ni la complexité de la ou des fonctions. C'est pour cela que j'ai prévu aussi une génération de squelette de code à partir de cette description, pour pouvoir l'aménager en cas de fn très compliquées ou de volumétrie importante.
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Bonjour
Merci de ta réponse,
Daniel a écrit :
Bonsoir,
Tout dépend de la volumétrie, et de la complexité de la
fonction. C'est discutable, et il est évident que ce qui va
s'appliquer sur 5000 lignes et qui est acceptable en terme de temps le
sera moins sur 1 million de lignes.
A titre d'exemple, j'avais fait une "moulinette" qui devais extraire
100 000 lignes d'une table sous Mysql et surtout reprendre le contenu
d'un longtext pour le recréer des tables et colonnes, le résultat
final était une table avec quelques millions de lignes.
C'est un peu cela mon pb. C'est un outil générique d'ETL sur mes bases.
Donc à fortiori, je ne connaîs pas la volumétrie, ni la table
concernée, ni la complexité de la ou des fonctions.
C'est pour cela que j'ai prévu aussi une génération de squelette de
code à partir de cette description, pour pouvoir l'aménager en cas de
fn très compliquées ou de volumétrie importante.
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Bonsoir, Tout dépend de la volumétrie, et de la complexité de la fonction. C'est discutable, et il est évident que ce qui va s'appliquer sur 5000 lignes et qui est acceptable en terme de temps le sera moins sur 1 million de lignes.
A titre d'exemple, j'avais fait une "moulinette" qui devais extraire 100 000 lignes d'une table sous Mysql et surtout reprendre le contenu d'un longtext pour le recréer des tables et colonnes, le résultat final était une table avec quelques millions de lignes.
C'est un peu cela mon pb. C'est un outil générique d'ETL sur mes bases. Donc à fortiori, je ne connaîs pas la volumétrie, ni la table concernée, ni la complexité de la ou des fonctions. C'est pour cela que j'ai prévu aussi une génération de squelette de code à partir de cette description, pour pouvoir l'aménager en cas de fn très compliquées ou de volumétrie importante.
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
