[Aide Conception]Stockage de 35 tableaux

Version imprimable

14/01/2014, 10h35
Dolphy35

[Aide Conception]Stockage de 35 tableaux

Bonjour,

Je travail avec WinDev depuis 3 mois. Je dois retranscrire un fichier Excel en application WinDev.

Etant plus habitué à Access, je me pose une question de conception par rapport à WinDev :

J'ai plusieurs tableaux qui contiennent des valeurs calculées par différentes fonctions. Le soucis est que je dois stocker ces données afin d'en extraire des informations pour d'autres calcul. J'aimerai avoir votre retour d'expérience à savoir comment stocker ces données.

:fleche: les tableaux possèdent 7 colonnes par ~70 lignes qui peuvent ou non avoir des données. j'ai 7 typologies qui ont 5 tableaux chacun ce qui donnent 35 tableaux d'une même structure.

Solution 1 : créer 35 champs tables dans la fenêtres, juste pour le traitement, sans affichage. Je ne sais pas si au niveau ressources ceci va alourdir le fonctionnement.

Solution 2 : Fichier ini, le niveau de hiérarchisation étant très faible, cela me bloque un peu. Je ne connais pas les fonctions permettant de travailler sur des fichiers ini, comptage d'éléments d'un même groupe.

Solution 3 : Fichier XML, le niveau de hiérarchisation étant illimité, ceci conviendrait, mais là aussi je ne connais les fonctions permettant de traiter les XML. de ce que j'ai vu, il y a quelques fonctions intéressantes.

Solution 4 : Fichier de données FIC en rajoutant des colonnes pour hiérarchiser les données. Ce mode me plait car je peux récupérer plus d'informations par SQL, comme le max, le min car sur les autres solutions cela oblige à plus de traitement, je pense.

pour la solution 4, j'aimerais que ce fichier ne soit pas dans l'analyse et que je le créer à la volée.

merci pour retour et vos retour d'expériences.

Dolphy ;)
14/01/2014, 10h57
Dolphy35

re,

au lieu de créer 35 tableaux je pense créer 1 tableau structuré comme l'aurait été le fichier de données.

par contre est-il possible de réaliser des extractions de données par SQL dans une table ?
je regarde du côté de TableCherche()

@+ Dolphy
14/01/2014, 12h14
laurent30s

Pour créer un fichier à la volée regarde les fonctions HDécritFichier(), HDécritRubrique() et HCréation() (il existe même HDécritLiaison())

http://doc.pcsoft.fr/fr-FR/?hdecritrubrique_exemple

Bonjour

On peut aussi créer des fichiers HF par CREATE TABLE, mais je crois (à vérifier) que c'est possible à partir de la version 18 seulement

Autre possibilité : si tu préfères faire du SQL, tu peux utiliser SQLite qui est géré par Windev sans aucune installation supplémentaire

Un exemple simple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 cnxTest est une Connexion sdReq est une Source de Données sTxtReq est une chaîne cnxTest..Provider = hAccèsNatifSQLite cnxTest..Serveur = fRepExe() + ["\"] + "mabase.db" SI HOuvreConnexion(cnxTest) ALORS sTxtReq = [ CREATE TABLE MaTable ( IdMaTable int NOT Null UNIQUE , ColTest VARCHAR(30) NOT Null default('') ) ] SI HExécuteRequêteSQL(sdReq, cnxTest, hRequêteSansCorrection, sTxtReq) ALORS Info("table créée") SINON Erreur(HErreurInfo()) FIN HAnnuleDéclaration(sdReq) SINON Erreur(HErreurInfo()) FIN HFermeConnexion(cnxTest)
Et bien sur on n'a pas besoin d'analyse pour faire ça

A noter : si la base n'existe pas elle est créée à l'ouverture de la connexion

14/01/2014, 15h04
DelphiManiac

Dans tes propositions tu mélanges des solutions éphémères (table dans des fenêtres, solution 1) et des solutions ou tu stockes les informations (solutions 2, 3, 4)

Si c'est pour stocker temporairement en mémoire je préconiserais des tableaux d'objets, si c'est pour persister l'information, la solution 4 me paraît la plus appropriée.

Difficile de fournir plus de réponses, ne sachant si l'information doit être persisté et quel type d'accès tu dois faire a cette information, parcours séquentiel, accès par une clé, principalement de la lecture ou de l'écriture, si le critère de performance est a prendre en considération, enfin plein de questions ^^

Hello,

Citation:

Envoyé par laurent30s

Pour créer un fichier à la volée regarde les fonctions HDécritFichier(), HDécritRubrique() et HCréation() (il existe même HDécritLiaison())

http://doc.pcsoft.fr/fr-FR/?hdecritrubrique_exemple

Merci pour le lien, j'avais survoler mais en regardant en détail. J'arrive à créer un Fichier et le remplir. :ccool:
Citation:
Envoyé par hpascal
Bonjour

On peut aussi créer des fichiers HF par CREATE TABLE, mais je crois (à vérifier) que c'est possible à partir de la version 18 seulement

Autre possibilité : si tu préfères faire du SQL, tu peux utiliser SQLite qui est géré par Windev sans aucune installation supplémentaire

Un exemple simple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 cnxTest est une Connexion sdReq est une Source de Données sTxtReq est une chaîne cnxTest..Provider = hAccèsNatifSQLite cnxTest..Serveur = fRepExe() + ["\"] + "mabase.db" SI HOuvreConnexion(cnxTest) ALORS sTxtReq = [ CREATE TABLE MaTable ( IdMaTable int NOT Null UNIQUE , ColTest VARCHAR(30) NOT Null default('') ) ] SI HExécuteRequêteSQL(sdReq, cnxTest, hRequêteSansCorrection, sTxtReq) ALORS Info("table créée") SINON Erreur(HErreurInfo()) FIN HAnnuleDéclaration(sdReq) SINON Erreur(HErreurInfo()) FIN HFermeConnexion(cnxTest)
Et bien sur on n'a pas besoin d'analyse pour faire ça

A noter : si la base n'existe pas elle est créée à l'ouverture de la connexion
en fait le côté SQL m'intéresse pour en extraire les données avec les fonction intégrées tel que Min et Max avec une clause. Je vais étudier cette proposition.

:merci:

Citation:

Envoyé par DelphiManiac

Dans tes propositions tu mélanges des solutions éphémères (table dans des fenêtres, solution 1) et des solutions ou tu stockes les informations (solutions 2, 3, 4)

Si c'est pour stocker temporairement en mémoire je préconiserais des tableaux d'objets, si c'est pour persister l'information, la solution 4 me paraît la plus appropriée.

Difficile de fournir plus de réponses, ne sachant si l'information doit être persisté et quel type d'accès tu dois faire a cette information, parcours séquentiel, accès par une clé, principalement de la lecture ou de l'écriture, si le critère de performance est a prendre en considération, enfin plein de questions ^^

merci de t'intéresser à mon cas :aie:. En fait les données à stocker ne servent que pour le calcul. Il y a tellement de paramètre d'entrée et de calcul intermédiaire que j'ai déjà plusieurs variables tableaux, champs table et des matrices. Le fait de rajouter encore des tableaux m'amène la réflexion de la lourdeur de traitement. Cette application est pour une diffusion cliente et donc je n'ai pas la maîtrise des PCs hôtes. D'où ma réflexion.
De plus je dois récupérer les informations en fonctions de 3 critères, qui me donnent environ une dizaine d'enregistrements. sur ces enregistrements je dois récupérer en fonction de mon besoin la valeur Min, Max et Max Absolue.

@++ Dolphy

Vu que ces sont des données temporaires qui ne servent que pour le calcul, et que de plus, tu as un volume limité de données et que tu ne cherche qu'a en récupérer le min et le max, je ne passerais pas par des fichiers. Le code SQL sera toujours plus lent que de maintenir les données en mémoire dans des tableaux d'objets.

Passer par des requêtes SQL pour extraire le min et le max de 10 enregistrements me fait penser à sortir un bazooka pour tuer un moustique ;)

Tu créé une première classe qui stocke l'information élémentaire : Libellé, valeur par exemple.

Tu créé une deuxième classe qui stocke un tableau de valeurs élémentaires, dans cette deuxième classe, tu déclares une méthode "ajouter"qui permette de maintenir le min et le max des valeurs ajoutées sans devoir parcourir le tableau.

Exemple (vraiment fait à l'arrache)
Code:

1 2 3 4 5 6 7 8 9 CValeur est une Classe Libelle est une chaîne Valeur est un entier FIN PROCEDURE Constructeur() PROCEDURE Destructeur()
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 CListeValeur est une Classe listeValeur est un tableau dynamique de CValeur // A toi ici de bien initialiser les bornes minimales et maximales valeurMin est un entier = 9999999999 valeurMax est un entier = 0 FIN PROCEDURE Constructeur() PROCEDURE Destructeur() PROCEDURE ajouter(libelle est une chaîne, valeur est un entier) uneValeur est un CValeur dynamique <- allouer un CValeur uneValeur.Libelle = libelle uneValeur.Valeur = valeur TableauAjoute(listeValeur, uneValeur) SI valeur < valeurMin ALORS valeurMin = valeur FIN SI valeur > valeurMax ALORS valeurMax = valeur FIN
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 // Code de test uneListeDeValeur est une CListeValeur dynamique <- allouer un CListeValeur uneListeDeValeur.ajouter("test 02", 999) uneListeDeValeur.ajouter("test 01", 12) uneListeDeValeur.ajouter("test 03", 45) Trace("Valeur min = " + uneListeDeValeur.valeurMin) Trace("Valeur max = " + uneListeDeValeur.valeurMax) Trace("-------") Trace("Parcours des éléments du tableau.") POUR TOUT uneValeur DE uneListeDeValeur.listeValeur Trace(uneValeur.Libelle, uneValeur.Valeur) FIN
Le résultat de l’exécution :
Code:

1 2 3 4 5 6 7 Valeur min = 12 Valeur max = 999 ------- Parcours des éléments du tableau. test 02 999 test 01 12 test 03 45

14/01/2014, 17h07
Unkof

+1 DelphiManiac.

Y a rien de plus rapide que le travail en ram direct, surtout quand t'as pas les données dans une table, je ne vois vraiment pas l'intérêt de tout sortir du ou des fichiers Excel, mettre en table, et après faire le boulot. Autant lire les données du/des fichiers, et bosser en ram directement via tableau, pourquoi passer par une table ?

La seule chose, j'aurai même pas fait des classes pour ca (ca revient un peu au bazooka .. ^^) .. j'aurai juste fait une procédure.
14/01/2014, 17h24
Dolphy35

Citation:

Envoyé par Unkof

+1 DelphiManiac.

Y a rien de plus rapide que le travail en ram direct, surtout quand t'as pas les données dans une table, je ne vois vraiment pas l'intérêt de tout sortir du ou des fichiers Excel, mettre en table, et après faire le boulot. Autant lire les données du/des fichiers, et bosser en ram directement via tableau, pourquoi passer par une table ?

La seule chose, j'aurai même pas fait des classes pour ca (ca revient un peu au bazooka .. ^^) .. j'aurai juste fait une procédure.

Tout dépend des logiciels que tu utilise. je n'ai pas de retour avec WinDev (trop récent) mais dans certain cas il est plus facile de stocker les données afin de les extraire au lieu de stocker dans la mémoire et d'alourdir les traitements. J'ai remarqué que les développeurs WinDev aimait bien globaliser les variables et stocker en mémoire. N'ayant pas d'expérience avec WinDev je n'ai pas l'habitude de fonctionner de tel sorte. Ensuite je n'ai pas la maitrise des PCs où seront installé l'application, si le PCs est une vieille charrette, je ne veux pas que le client est un traitement de 5 min.

@DelphiManiac : je vais regarder ta proposition et te donne retour.

Merci

@++ Dolphy
14/01/2014, 17h54
Unkof

Moi perso je ne viens pas de l'univers WinDev. Je l'utilise, mais plus ca va, et moins je l'utilise, mais le sujet n'est pas là.

Les PC depuis 7 ou 8 ans ont plusieurs gigas de ram, si t'as 35 tables avec 490 valeurs (tu as dit en gros 7 colonnes sur 70 lignes), ca te fait un total d'environ 17150 valeurs, qui prennent .. allez, 8 octets chacune (on va dire..). On a donc un total de 137200 octets soit grosse modo 134Ko. Même dans l'hypothèse folle ou tes données prendraient allez, 80 Octets chacune, on serait à 1,34 Mo.

Pense-tu vraiment que 1,34 Mo de tableau puisse poser un problème à un pc aujourd'hui, ou même à un PC qui a 10 ans ?

L'optimisation pour la vitesse d'exécution passe toujours pas la ram, et l'optimisation de la ram passe toujours par le disque au détriment de la vitesse, charge à toi de voir quel est ton besoin. Si t'as besoin d'un truc optimisé au niveau RAM, n'utilises pas WinDev, quand tu vas voir la taille de ton exe, tu vas être surpris.
14/01/2014, 18h57
DelphiManiac

Citation:

Envoyé par Dolphy35

...J'ai remarqué que les développeurs WinDev aimait bien globaliser les variables et stocker en mémoire...

Juste une petite remarque que ce point, il n'y a vraiment aucun rapport entre utiliser à outrance des variables globales et travailler en mémoire ;)

Je ne suis pas une développeur Windev, à la base, je m'y suis mis par la force des choses. Je développe par ailleurs en c# actuellement, et je t'aurais proposer la même solution en c#, tout comme je l'aurais fait en Delphi dans un passé assez lointain !!

Concernant les lenteurs sur des PC anciens, si tu as un doute sur les performances de ces PC, tu peux être assuré que le problème de performance est généralement lié à des disques très faiblards et ce quelque soit la configuration. Mets un SSD dans un PC de 5 ans et tu as l'impression d'avoir un PC tout neuf.
14/01/2014, 19h39
Dolphy35

Citation:

Envoyé par Unkof

Moi perso je ne viens pas de l'univers WinDev. Je l'utilise, mais plus ca va, et moins je l'utilise, mais le sujet n'est pas là.

Les PC depuis 7 ou 8 ans ont plusieurs gigas de ram, si t'as 35 tables avec 490 valeurs (tu as dit en gros 7 colonnes sur 70 lignes), ca te fait un total d'environ 17150 valeurs, qui prennent .. allez, 8 octets chacune (on va dire..). On a donc un total de 137200 octets soit grosse modo 134Ko. Même dans l'hypothèse folle ou tes données prendraient allez, 80 Octets chacune, on serait à 1,34 Mo.

Pense-tu vraiment que 1,34 Mo de tableau puisse poser un problème à un pc aujourd'hui, ou même à un PC qui a 10 ans ?

L'optimisation pour la vitesse d'exécution passe toujours pas la ram, et l'optimisation de la ram passe toujours par le disque au détriment de la vitesse, charge à toi de voir quel est ton besoin. Si t'as besoin d'un truc optimisé au niveau RAM, n'utilises pas WinDev, quand tu vas voir la taille de ton exe, tu vas être surpris.

Ceci est une discussion ouverte. J'en fait appel à vos expériences car je connais peu WinDev, certes présenté comme ceci, cela fait peu mais comme expliqué plus haut j'ai déjà plein de tableaux mémoires et des matrices. Ensuite l'application réalise beaucoup de calcul matriciel et autre calculs. Ensuite si ton expérience dit que cela peu le faire, ensuite ma question portait également sur les traitements de ces données, à savoir le plus simple à extraire pour mon besoin.

Citation:

Envoyé par DelphiManiac

Juste une petite remarque que ce point, il n'y a vraiment aucun rapport entre utiliser à outrance des variables globales et travailler en mémoire ;)

Je ne suis pas une développeur Windev, à la base, je m'y suis mis par la force des choses. Je développe par ailleurs en c# actuellement, et je t'aurais proposer la même solution en c#, tout comme je l'aurais fait en Delphi dans un passé assez lointain !!

Concernant les lenteurs sur des PC anciens, si tu as un doute sur les performances de ces PC, tu peux être assuré que le problème de performance est généralement lié à des disques très faiblards et ce quelque soit la configuration. Mets un SSD dans un PC de 5 ans et tu as l'impression d'avoir un PC tout neuf.

pour moi une variable globale est toujours stockée tant que l'application est ouverte donc utilise de la ressource.

Bon la Question part en débat d'utilisation ressource :mouarf:, vous m'avez convaincu que je peux utiliser les variables tableaux dans mon cas.
Ensuite il y avait le point d'extraire les données selon besoin.

Maintenant je vais tester ta proposition.

:merci:

@++ Dolphy
15/01/2014, 17h47
Unkof

Citation:

Envoyé par Dolphy35

l'application réalise beaucoup de calcul matriciel et autre calculs.

Ben raison de plus pour bosser en ram si tu as des calculs plus ou moins lourds à effectuer derrière ... :mrgreen:

Enfin, chacun fait comme il veut .. :)
15/01/2014, 21h00
Dolphy35

Citation:

Envoyé par Unkof

Ben raison de plus pour bosser en ram si tu as des calculs plus ou moins lourds à effectuer derrière ... :mrgreen:

Enfin, chacun fait comme il veut .. :)

tout à fait.

J'effectuerais des tests une fois que j'aurai plus de temps entre calcul avec stockage RAM et Stockage Fichier afin de déterminer les ressources utilisées.

@ DelphiManiac : j'ai repris ton principe d'utilisation d'une classe. Merci pour l'orientation.

@+ Dolphy