|
PROFESSIONAL NEWSGROUPS
WINDEV, WEBDEV and WINDEV Mobile |
| | | | | |
| Home → WINDEV 2024 → Optimiser unet table fichier liée à plusieurs fichiers |
| Optimiser unet table fichier liée à plusieurs fichiers |
| Started by Gilles, Feb., 16 2017 12:55 PM - 11 replies |
| |
| | | |
|
| |
Registered member
160 messages
Popularité : +1 (3 votes) |
|
Posted on February, 16 2017 - 12:55 PM |
Bonjour,
j'ai une table fichier (tableM) liée à un fichier principal (définie par contenu) qui comprend un clé étrangère.
Pour l'affichage de la tableM, j'ai d'abord utilisé le plus simple : la solution multi-fichier avec fichier relié. J'ai trouvé l'affichage un peu lent.
J'ai alors créé une seconde table fichier (tableS) chargée par le fichier reliée (définie par contenu).
Dans la tableM, les champs multi-fichier initialement deviennent des champs calculés (non liés) et j'utilise alors le code de l'affichage de chaque ligne "Affichage d'une ligne de tableM". C'est nettement plus rapide.
Mais malheureusement les 2 tables semblent se charger en parallèle dans le processus d'initialisation de la fenêtre. Or pour que cela fonctionne bien, il faudrait que la table principale se charge après la table secondaire. Y a-t-il moyen de gérer cette séquence ?
Merci. Cordialement. Gilles |
| |
| |
| | | |
|
| | |
| |
Posted on February, 16 2017 - 1:51 PM |
Bonjour,
Voyez typiquement FenInitialisée() pour cela.
Bon travail
Hemgé |
| |
| |
| | | |
|
| | |
| |
Posted on February, 16 2017 - 2:03 PM |
Bonjour Gilles
dans le code d'init de la table que tu ne veux pas charger au départ,
met le fichier relié à vide (c'est une propriété de la table).
Quand tu veux qu'elle se charge, remets le fichier relié à la bonne
valeur (après avroi fait un hfiltre sur ce fichier, par exemple)
OU alors tu pourrais remplacer tout ton truc par une requête
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)
Plus d'information sur http://fabriceharari.com
Le 2/16/2017 à 6:55 AM, Gilles a écrit :
Bonjour,
j'ai une table fichier (tableM) liée à un fichier principal (définie par
contenu) qui comprend un clé étrangère.
Pour l'affichage de la tableM, j'ai d'abord utilisé le plus simple : la
solution multi-fichier avec fichier relié. J'ai trouvé l'affichage un
peu lent.
J'ai alors créé une seconde table fichier (tableS) chargée par le
fichier reliée (définie par contenu).
Dans la tableM, les champs multi-fichier initialement deviennent des
champs calculés (non liés) et j'utilise alors le code de l'affichage de
chaque ligne "Affichage d'une ligne de tableM". C'est nettement plus
rapide.
Mais malheureusement les 2 tables semblent se charger en parallèle dans
le processus d'initialisation de la fenêtre. Or pour que cela fonctionne
bien, il faudrait que la table principale se charge après la table
secondaire. Y a-t-il moyen de gérer cette séquence ?
Merci. Cordialement. Gilles |
| |
| |
| | | |
|
| | |
| |
Registered member
160 messages
Popularité : +1 (3 votes) |
|
Posted on February, 16 2017 - 6:02 PM |
Bonjour Hemgé,
l'emploi de FenInitialisée() me semble difficile dans ce cas-là. A moins que je ne vois pas le truc comme dirait Fabrice.
Bonjour Fabrice,
effectivement je suis revenu aux requêtes "vite fait bien fait" pour l'affichage des tables ! Et là pas de problème. Je voulais voir ce que cela donnait. C'est donc jouable avec les fichiers mais moins performant que les requêtes.
Merci pour votre aide à tous les deux. Cordialement. Gilles |
| |
| |
| | | |
|
| | |
| |
Posted on February, 16 2017 - 7:00 PM |
Re...
effectivement je suis revenu aux requêtes "vite fait bien fait" pour
l'affichage des tables ! Et là pas de problème. Je voulais voir ce que
cela donnait. C'est donc jouable avec les fichiers mais moins performant
que les requêtes.
Je n'ai PAS dit qu'une solution était plus performante que l'autre.
J'ai dis que c'était possible des 2 manières. Laquelle utiliser dépend
de ce qu'on a à faire (et en général des petits détails qui ne sont pas
décrits dans les messages)
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)
Plus d'information sur http://fabriceharari.com |
| |
| |
| | | |
|
| | |
| |
Registered member
160 messages
Popularité : +1 (3 votes) |
|
Posted on February, 17 2017 - 9:00 AM |
Bonjour Fabrice,
à mon avis, les requêtes sont nettement plus rapides. Avec ma version 18, j'ai fait il y a quelques temps toute une batterie de tests aussi bien sur des serveurs HyperFile (Windows et Linux) que sur des bases MySQL et PostgreSQL avec les accès natifs de Windev. D'ailleurs pour ces 2 derniers j'ai comparé aussi avec des accès Delphi/Lazarus et Qt. Il en ressort que les HLit... & Co sont moins performants en lecture/écriture dans tous les cas que j'ai testés. Par contre avec Windev,, dans les bases non HyperFile, les blocages sont nettement plus contraignants et difficiles à optimiser même en réglant de manière fine les "lock timeout" des serveurs. Enfin avec des HExécuteRequêteSQL sur un serveur HyperFile Linux 64 et un serveur MariaDB ou PostgreSQL, les 2 derniers sont un peu plus rapides mais pas au point à mon avis de ne pas utiliser HyperFile d'autant que mes projets utilisent des accès concurrentiels et donc des verrous, domaine où HyperFile me convient bien mieux que les 2 serveurs cités (en utilisation Windev).
Hier, je maquettais rapidement une fenêtre avec 1 table principale et 3 tables secondaires (donc 3 clés étrangères). La table principale comprend 6000 enregistrements. Avec une table multi-fichier le temps d'affichage est d'environ 6 secondes. Avec HExécuteRequêteSQL il est quasi-instantané (1s) ... et avec la méthode que vous avez évoquée, il faut compter un peu plus de 3 secondes, le tout sur un disque ssd local.
Pour le reste, chacun fait comme il veut et chacun a sa problématique. Je ne dis pas que les fonctions HModifie... sont à bannir, loin de là : Je les utilise souvent dans les écritures mais pour la lecture (sujet de l'optimisation) , je préfère finalement de loin les HExécuteRequêteSQL.
En tout cas, merci pour votre aide. 
Bonne journée. Gilles.Message modified, February, 17 2017 - 9:11 AM |
| |
| |
| | | |
|
| | |
| |
Posted on February, 17 2017 - 1:09 PM |
Bonjour GIlles,
> à mon avis, les requêtes sont nettement plus rapides. Avec ma version
Contre exemple :
Dans un soft de mail, j'ai besoin d'afficher tous les emails de la inbox
dans une table. Il peut y en avoir 50000 (ou plus).
Si je fais une requête, je lis tout le fichier, et ca prend un temps fou.
Si à la place je fais un hfiltre sur la bonne clé composé et lie la
table directement au fichier (donc accès direct ligne par ligne),
affichage instantané.
Bien sur, si l'utilisateur s'amuse à scroller dans tous les emails, ca
sera plus long qu'avec la requête, mais c'est un cas qui n'arrive
pratiquement jamais, vu que tout le monde passe son temps dans les 3
premières pages de la inbox.
Donc, la requête est plus rapide en théorie, mais dans ce cas précis,
beaucoup plus longue pour l'utilisateur.
C'est pour ce genre de raison qu'on rencontre régulièrement dans la VRAI
vie que je me méfie comme de la peste des principes généraux qui disent
qu'il faut toujours travailler comme ceci ou comme celà.
Il faut comprendre ce qui se passe derrière l'interface et choisir la
méthode la plus adaptée au cas spécifique.
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)
Plus d'information sur http://fabriceharari.com |
| |
| |
| | | |
|
| | |
| |
Registered member
88 messages
Popularité : +2 (4 votes) |
|
Posted on February, 18 2017 - 4:00 PM |
Bonjour Fabrice,
Je fais appel à votre expérience.
A partir d'un fichier HFSQL Email regroupant tous les mails du domaine y.com, si je veux récupérer dans un tableau que les mails adressés à x@y.com, est ce que le parcours d'une vue qui a été créée sur Email avec une condition de sélection sur la rubrique destinataire ("Email.Destinataire="'x@y.com'") permettra d'améliorer le temps du traitement (et de réduire l'utilisation du réseau ou de la connexion internet) par rapport au parcours de Email filtré ?
Cordialement |
| |
| |
| | | |
|
| | |
| |
Registered member
160 messages
Popularité : +1 (3 votes) |
|
Posted on February, 19 2017 - 10:53 AM |
Bonjour Fabrice,
comme vous le dites, dans la vraie vie on rencontre plusieurs cas de figures. Et le mien -exprimé ici- est de lire tous les enregistrements d'une traite. Donc la vitesse de chargement est importante. Pourquoi utiliser une table ? Pour réaliser plus simplement des calculs intermédiaires (lors de l'affichage des lignes) et pour visualiser certains champs. Dans cet exercice, j'ai comparé aussi comparé l'affichage dans une table mémoire.
Ma conclusion n'est pas générale. Mais dans le cas d'un traitement statistique de données, comme le mien, elle s'applique.
Cordialement. Gilles |
| |
| |
| | | |
|
| | |
| |
Posted on February, 20 2017 - 3:39 PM |
Bonjour
ca dépend si récupérer veut dire afficher le début, et très rarement
scroller dans le reste, ou si tu as des traitements à faire sur toutes
les lignes...
Et c'est déjà ce que j'explique dans mon message précédent
Cordialement
--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International
A votre disposition : WXShowroom.com, WXReplication (open source) et
maintenant WXEDM (open source)
Plus d'information sur http://fabriceharari.com
Le 2/18/2017 à 10:00 AM, Sylvain RICAU a écrit :
Bonjour Fabrice,
Je fais appel à votre expérience.
A partir d'un fichier HFSQL Email regroupant tous les mails du domaine
y.com, si je veux récupérer dans un tableau que les mails adressés à
x@y.com, est ce que le parcours d'une vue qui a été créée sur Email avec
une condition de sélection sur la rubrique destinataire
("Email.Destinataire="'x@y.com'") permettra d'améliorer le temps du
traitement (et de réduire l'utilisation du réseau ou de la connexion
internet) par rapport au parcours de Email filtré ?
Cordialement |
| |
| |
| | | |
|
| | |
| |
Registered member
88 messages
Popularité : +2 (4 votes) |
|
Posted on February, 21 2017 - 8:02 AM |
Bonjour Fabrice,
Je me suis mal exprimé : au lieu de "récupérer" j'aurais dû utiliser "charger en mémoire dans un tableau".
J'ai effectivement un grand nombre de traitement avec chaque ligne du tableau.
Ce tableau n'est pas uniquement utilisé pour de l'affichage.
Merci pour votre retour après ces précisions. |
| |
| |
| | | |
|
| | |
| |
Posted on February, 21 2017 - 12:28 PM |
Si il FAUT charger toutes les lignes, comme on l'a déjà expliqué plus
haut plusieurs fois, il vaut mieux faire une requête.
Le 2/21/2017 à 2:02 AM, Sylvain RICAU a écrit :
Bonjour Fabrice,
Je me suis mal exprimé : au lieu de "récupérer" j'aurais dû utiliser
"charger en mémoire dans un tableau".
J'ai effectivement un grand nombre de traitement avec chaque ligne du
tableau.
Ce tableau n'est pas uniquement utilisé pour de l'affichage.
Merci pour votre retour après ces précisions. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|