Bonjour à tous,
Nous investiguons Windev 7.x depuis 14 mois dès que nous avons un moment
libre afin de nous assurer que cet environnement de développement soit
adéquant pour nos développements commerciaux sur mesure.
A ce jour, nous pourrions dire que de nombreuses fonctions et ordres de
programmation en Windev sont plus puissantes que ceux de notre langage
actuel et le concept général est supérieur.
Par contre, les quelques tests que nous avons effectués sur les bases de
données HF (avec index ou requêtes SQL) se sont avérés beaucoup plus
que notre langage actuel Foxpro. Ce qui risque de nous mettre dans
l'embarras face à notre clientèle qui ne cesse de nous faire remarquer la
vitesse époustouflante
Mais, comme tout est relatif dans la vie, une vitesse d'exécution et
d'affichage des données est toujours comparative.
Par exemple, si nous suivons une clef d'une table fichier dans un Browse
25 lignes (comme votre WDMAP), le langage que nous utilisons ne va
'chercher' que ces 25 rubriques et le résultat est toujours instantané
que soit le nombre total d'enregistrements. Quand nous appuyons sur "Page
Down", il va "chercher" les 25 suivants et ainsi de suite. Ce qui fait
dans ce cas, c'est toujours instantané.
Bien sûr que si nous utilisons une requête SQL pour aller "chercher" tous
les enregistrements de cette clef, cela risque d'être un peu plus long
le nombre d'enregistrements trouvés parce que la requête ira chercher tous
les éléments qui répondent à la condition.
Voici un autre exemple pour mieux comprendre ce que nous entendons par
vitesse.
Dans une de nos applications pour la Gestion de Clubs Vidéos, le processus
de préparation d'un nouveau mois fait la maintenance de 36 fichiers. Voici
un cas type.
C'est un processus plus ou moins complexe qui parcoure les tables fichiers
principales suivantes;
6300 enreg. Clients, lecture/écriture de chaque enreg. (transfert de
6800 enreg. Films, lecture/écriture de chaque enreg. (transfert de soldes)
2200 Comptes à recevoir, manipulations complexes et réécriture
706 Produits/Services, lectures/écriture de chaque enreg. (transfert de
soldes)
9336 Factures détaillées dans un champ mémo
75725 Historiques des locations, élimination des périmées
... et ainsi de suite.
Nous avons environ 4 clefs par fichier.
Le processus va aussi effacer et recréer tous les index de tous les
en éliminant les enregistrements effacés.
Un client installé avec un vieux Pentium 450 et Windows 98 nous a informé
son inquiétude que le processus total prenait environ 25 minutes à se
compléter. Selon lui, ce long processus ne cadrait pas avec la vitesse d'
exécution à laquelle il était habitué depuis de nombreuses années avec
application.
Hors, la réindexation seule de ces 36 fichiers (effacer et recréer chacun
des index) prend environ 15 secondes au total. Pas pour chacun des
15 secondes pour les 36 fichiers. Ça c'est de la vitesse!
Nous avons retravaillé la logique du processus mensuel et ce même client
complète maintenant ce processus complet en moins de 3 minutes -
réindexations comprises. Il est très content.
Voilà la vitesse à laquelle nous sommes habitué.
Autre exemple, nous avons un autre magasin qui a à peu près les mêmes
données que cité plus haut sauf que lui, il a plus de 37 000 clients
(membres). Une réindexation complète de ses 36 tables fichiers prend moins
de 30 secondes sur son Pentium 800 (réseau 5 postes avec Windows 98).
Nous ne touchons pas à la base de registre.
Peut-on s'attendre à un rendement semblable avec Windev?
Rien ne nous ferait plus plaisir que de lire des réponses positives.
Cordialement,
Réal Philippon
Programmation Ultra Ltée -o- www.ultra.ca
L'informatique sur mesure depuis plus de 24 ans
Bonjour à tous,
Nous investiguons Windev 7.x depuis 14 mois dès que nous avons un moment
libre afin de nous assurer que cet environnement de développement soit
adéquant pour nos développements commerciaux sur mesure.
A ce jour, nous pourrions dire que de nombreuses fonctions et ordres de
programmation en Windev sont plus puissantes que ceux de notre langage
actuel et le concept général est supérieur.
Par contre, les quelques tests que nous avons effectués sur les bases de
données HF (avec index ou requêtes SQL) se sont avérés beaucoup plus
que notre langage actuel Foxpro. Ce qui risque de nous mettre dans
l'embarras face à notre clientèle qui ne cesse de nous faire remarquer la
vitesse époustouflante
Mais, comme tout est relatif dans la vie, une vitesse d'exécution et
d'affichage des données est toujours comparative.
Par exemple, si nous suivons une clef d'une table fichier dans un Browse
25 lignes (comme votre WDMAP), le langage que nous utilisons ne va
'chercher' que ces 25 rubriques et le résultat est toujours instantané
que soit le nombre total d'enregistrements. Quand nous appuyons sur "Page
Down", il va "chercher" les 25 suivants et ainsi de suite. Ce qui fait
dans ce cas, c'est toujours instantané.
Bien sûr que si nous utilisons une requête SQL pour aller "chercher" tous
les enregistrements de cette clef, cela risque d'être un peu plus long
le nombre d'enregistrements trouvés parce que la requête ira chercher tous
les éléments qui répondent à la condition.
Voici un autre exemple pour mieux comprendre ce que nous entendons par
vitesse.
Dans une de nos applications pour la Gestion de Clubs Vidéos, le processus
de préparation d'un nouveau mois fait la maintenance de 36 fichiers. Voici
un cas type.
C'est un processus plus ou moins complexe qui parcoure les tables fichiers
principales suivantes;
6300 enreg. Clients, lecture/écriture de chaque enreg. (transfert de
6800 enreg. Films, lecture/écriture de chaque enreg. (transfert de soldes)
2200 Comptes à recevoir, manipulations complexes et réécriture
706 Produits/Services, lectures/écriture de chaque enreg. (transfert de
soldes)
9336 Factures détaillées dans un champ mémo
75725 Historiques des locations, élimination des périmées
... et ainsi de suite.
Nous avons environ 4 clefs par fichier.
Le processus va aussi effacer et recréer tous les index de tous les
en éliminant les enregistrements effacés.
Un client installé avec un vieux Pentium 450 et Windows 98 nous a informé
son inquiétude que le processus total prenait environ 25 minutes à se
compléter. Selon lui, ce long processus ne cadrait pas avec la vitesse d'
exécution à laquelle il était habitué depuis de nombreuses années avec
application.
Hors, la réindexation seule de ces 36 fichiers (effacer et recréer chacun
des index) prend environ 15 secondes au total. Pas pour chacun des
15 secondes pour les 36 fichiers. Ça c'est de la vitesse!
Nous avons retravaillé la logique du processus mensuel et ce même client
complète maintenant ce processus complet en moins de 3 minutes -
réindexations comprises. Il est très content.
Voilà la vitesse à laquelle nous sommes habitué.
Autre exemple, nous avons un autre magasin qui a à peu près les mêmes
données que cité plus haut sauf que lui, il a plus de 37 000 clients
(membres). Une réindexation complète de ses 36 tables fichiers prend moins
de 30 secondes sur son Pentium 800 (réseau 5 postes avec Windows 98).
Nous ne touchons pas à la base de registre.
Peut-on s'attendre à un rendement semblable avec Windev?
Rien ne nous ferait plus plaisir que de lire des réponses positives.
Cordialement,
Réal Philippon
Programmation Ultra Ltée -o- www.ultra.ca
L'informatique sur mesure depuis plus de 24 ans
Bonjour à tous,
Nous investiguons Windev 7.x depuis 14 mois dès que nous avons un moment
libre afin de nous assurer que cet environnement de développement soit
adéquant pour nos développements commerciaux sur mesure.
A ce jour, nous pourrions dire que de nombreuses fonctions et ordres de
programmation en Windev sont plus puissantes que ceux de notre langage
actuel et le concept général est supérieur.
Par contre, les quelques tests que nous avons effectués sur les bases de
données HF (avec index ou requêtes SQL) se sont avérés beaucoup plus
que notre langage actuel Foxpro. Ce qui risque de nous mettre dans
l'embarras face à notre clientèle qui ne cesse de nous faire remarquer la
vitesse époustouflante
Mais, comme tout est relatif dans la vie, une vitesse d'exécution et
d'affichage des données est toujours comparative.
Par exemple, si nous suivons une clef d'une table fichier dans un Browse
25 lignes (comme votre WDMAP), le langage que nous utilisons ne va
'chercher' que ces 25 rubriques et le résultat est toujours instantané
que soit le nombre total d'enregistrements. Quand nous appuyons sur "Page
Down", il va "chercher" les 25 suivants et ainsi de suite. Ce qui fait
dans ce cas, c'est toujours instantané.
Bien sûr que si nous utilisons une requête SQL pour aller "chercher" tous
les enregistrements de cette clef, cela risque d'être un peu plus long
le nombre d'enregistrements trouvés parce que la requête ira chercher tous
les éléments qui répondent à la condition.
Voici un autre exemple pour mieux comprendre ce que nous entendons par
vitesse.
Dans une de nos applications pour la Gestion de Clubs Vidéos, le processus
de préparation d'un nouveau mois fait la maintenance de 36 fichiers. Voici
un cas type.
C'est un processus plus ou moins complexe qui parcoure les tables fichiers
principales suivantes;
6300 enreg. Clients, lecture/écriture de chaque enreg. (transfert de
6800 enreg. Films, lecture/écriture de chaque enreg. (transfert de soldes)
2200 Comptes à recevoir, manipulations complexes et réécriture
706 Produits/Services, lectures/écriture de chaque enreg. (transfert de
soldes)
9336 Factures détaillées dans un champ mémo
75725 Historiques des locations, élimination des périmées
... et ainsi de suite.
Nous avons environ 4 clefs par fichier.
Le processus va aussi effacer et recréer tous les index de tous les
en éliminant les enregistrements effacés.
Un client installé avec un vieux Pentium 450 et Windows 98 nous a informé
son inquiétude que le processus total prenait environ 25 minutes à se
compléter. Selon lui, ce long processus ne cadrait pas avec la vitesse d'
exécution à laquelle il était habitué depuis de nombreuses années avec
application.
Hors, la réindexation seule de ces 36 fichiers (effacer et recréer chacun
des index) prend environ 15 secondes au total. Pas pour chacun des
15 secondes pour les 36 fichiers. Ça c'est de la vitesse!
Nous avons retravaillé la logique du processus mensuel et ce même client
complète maintenant ce processus complet en moins de 3 minutes -
réindexations comprises. Il est très content.
Voilà la vitesse à laquelle nous sommes habitué.
Autre exemple, nous avons un autre magasin qui a à peu près les mêmes
données que cité plus haut sauf que lui, il a plus de 37 000 clients
(membres). Une réindexation complète de ses 36 tables fichiers prend moins
de 30 secondes sur son Pentium 800 (réseau 5 postes avec Windows 98).
Nous ne touchons pas à la base de registre.
Peut-on s'attendre à un rendement semblable avec Windev?
Rien ne nous ferait plus plaisir que de lire des réponses positives.
Cordialement,
Réal Philippon
Programmation Ultra Ltée -o- www.ultra.ca
L'informatique sur mesure depuis plus de 24 ans
> En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
206g. Il n'y a plus les ralentissements lors d'accès multi-utilisateurs.
contre, la rapidité est toujours nettement inférieure aux requêtes de
Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
Cela dépend biensûr aussi du matériel.
Le facteur principal de la lenteur des requêtes Windev / HF est que tous
enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de tri
et calcul sur le résultat Windev est plus rapide puisque la lecture est
complété en arrière plan. Il y a des gens qui disent que la 8 est plus
rapide, d'autres disent que c'est toujours lent. Aussi longtemps que les
résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
des gens soucieux de rapidité.
> En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
206g. Il n'y a plus les ralentissements lors d'accès multi-utilisateurs.
contre, la rapidité est toujours nettement inférieure aux requêtes de
Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
Cela dépend biensûr aussi du matériel.
Le facteur principal de la lenteur des requêtes Windev / HF est que tous
enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de tri
et calcul sur le résultat Windev est plus rapide puisque la lecture est
complété en arrière plan. Il y a des gens qui disent que la 8 est plus
rapide, d'autres disent que c'est toujours lent. Aussi longtemps que les
résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
des gens soucieux de rapidité.
> En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
206g. Il n'y a plus les ralentissements lors d'accès multi-utilisateurs.
contre, la rapidité est toujours nettement inférieure aux requêtes de
Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
Cela dépend biensûr aussi du matériel.
Le facteur principal de la lenteur des requêtes Windev / HF est que tous
enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de tri
et calcul sur le résultat Windev est plus rapide puisque la lecture est
complété en arrière plan. Il y a des gens qui disent que la 8 est plus
rapide, d'autres disent que c'est toujours lent. Aussi longtemps que les
résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
des gens soucieux de rapidité.
> En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
version
> 206g. Il n'y a plus les ralentissements lors d'accès multi-utilisateurs.
Par
> contre, la rapidité est toujours nettement inférieure aux requêtes de
Visual
> Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
> tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
lieu
> de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
Ghz).
> Cela dépend biensûr aussi du matériel.
> Le facteur principal de la lenteur des requêtes Windev / HF est que tous
les
> enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de
> et calcul sur le résultat Windev est plus rapide puisque la lecture est
> complété en arrière plan. Il y a des gens qui disent que la 8 est plus
> rapide, d'autres disent que c'est toujours lent. Aussi longtemps que les
> résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
pour
> des gens soucieux de rapidité.
Bonjour,
Pour avoir une vitesse quasi instantanée pour des requetes sur des
HF, il faut que tous les champs de fichier concernés par la requete soient
indexés, faites l'essai et vous serez surpris. Les résultats sont très
voisins dans ce cas de ceux de VFP.
Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
filtres sur les fichiers HF, sur de très gros fichiers c'est encore plus
rapide, par contre ces filtres sont un peu plus difficiles à programmer
les requetes, mais quand on pratique un peu cela devient vite assez
Sincères Salutations
--
Jean-Claude FLAJOULOT
Sécurité Pointage & Biométrie
(Otez _no_spam pour me contacter en PV)
http://perso.wanadoo.fr/securite.pointage.et.biometrie/
> En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
version
> 206g. Il n'y a plus les ralentissements lors d'accès multi-utilisateurs.
Par
> contre, la rapidité est toujours nettement inférieure aux requêtes de
Visual
> Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
> tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
lieu
> de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
Ghz).
> Cela dépend biensûr aussi du matériel.
> Le facteur principal de la lenteur des requêtes Windev / HF est que tous
les
> enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de
> et calcul sur le résultat Windev est plus rapide puisque la lecture est
> complété en arrière plan. Il y a des gens qui disent que la 8 est plus
> rapide, d'autres disent que c'est toujours lent. Aussi longtemps que les
> résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
pour
> des gens soucieux de rapidité.
Bonjour,
Pour avoir une vitesse quasi instantanée pour des requetes sur des
HF, il faut que tous les champs de fichier concernés par la requete soient
indexés, faites l'essai et vous serez surpris. Les résultats sont très
voisins dans ce cas de ceux de VFP.
Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
filtres sur les fichiers HF, sur de très gros fichiers c'est encore plus
rapide, par contre ces filtres sont un peu plus difficiles à programmer
les requetes, mais quand on pratique un peu cela devient vite assez
Sincères Salutations
--
Jean-Claude FLAJOULOT
Sécurité Pointage & Biométrie
SPetB_no_spam@wandoo.fr
(Otez _no_spam pour me contacter en PV)
http://perso.wanadoo.fr/securite.pointage.et.biometrie/
> En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
version
> 206g. Il n'y a plus les ralentissements lors d'accès multi-utilisateurs.
Par
> contre, la rapidité est toujours nettement inférieure aux requêtes de
Visual
> Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
> tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
lieu
> de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
Ghz).
> Cela dépend biensûr aussi du matériel.
> Le facteur principal de la lenteur des requêtes Windev / HF est que tous
les
> enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de
> et calcul sur le résultat Windev est plus rapide puisque la lecture est
> complété en arrière plan. Il y a des gens qui disent que la 8 est plus
> rapide, d'autres disent que c'est toujours lent. Aussi longtemps que les
> résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
pour
> des gens soucieux de rapidité.
Bonjour,
Pour avoir une vitesse quasi instantanée pour des requetes sur des
HF, il faut que tous les champs de fichier concernés par la requete soient
indexés, faites l'essai et vous serez surpris. Les résultats sont très
voisins dans ce cas de ceux de VFP.
Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
filtres sur les fichiers HF, sur de très gros fichiers c'est encore plus
rapide, par contre ces filtres sont un peu plus difficiles à programmer
les requetes, mais quand on pratique un peu cela devient vite assez
Sincères Salutations
--
Jean-Claude FLAJOULOT
Sécurité Pointage & Biométrie
(Otez _no_spam pour me contacter en PV)
http://perso.wanadoo.fr/securite.pointage.et.biometrie/
[CUT]
Avec Windev en un an de travail, j'ai passée des journées entières pour la
recherche d'optimisations, sans pour autant trouver une solution valable
généralement.
Ne faisant non plus confiance à moi seul, j'ai travaillé
dessus avec un spécialiste de SQL.
Pour l'instant je n'ai jamais lu que
quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
en réseau, avec plusieurs milliers de résultats triés, en moins d'une
seconde.
Le problème s'aggrave encore quand on a une base avec un minimum de
redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
produit et ne pas celui du groupe de produits ou d'un domaine d'affaires,
qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
requêtes en mettant ces rubriques dans les lignes de commandes. Mais c'est
ça le but de données relationnelles?
En ce qui concerne les filtres, je préfère les requêtes d'abord parce
travaille sur une copie des données en local (question réseau). Mais aussi
parce que cela me donne plus de flexibilité pour les liaisons et rend
les rubriques triable, sans index.
[CUT]
Avec Windev en un an de travail, j'ai passée des journées entières pour la
recherche d'optimisations, sans pour autant trouver une solution valable
généralement.
Ne faisant non plus confiance à moi seul, j'ai travaillé
dessus avec un spécialiste de SQL.
Pour l'instant je n'ai jamais lu que
quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
en réseau, avec plusieurs milliers de résultats triés, en moins d'une
seconde.
Le problème s'aggrave encore quand on a une base avec un minimum de
redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
produit et ne pas celui du groupe de produits ou d'un domaine d'affaires,
qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
requêtes en mettant ces rubriques dans les lignes de commandes. Mais c'est
ça le but de données relationnelles?
En ce qui concerne les filtres, je préfère les requêtes d'abord parce
travaille sur une copie des données en local (question réseau). Mais aussi
parce que cela me donne plus de flexibilité pour les liaisons et rend
les rubriques triable, sans index.
[CUT]
Avec Windev en un an de travail, j'ai passée des journées entières pour la
recherche d'optimisations, sans pour autant trouver une solution valable
généralement.
Ne faisant non plus confiance à moi seul, j'ai travaillé
dessus avec un spécialiste de SQL.
Pour l'instant je n'ai jamais lu que
quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
en réseau, avec plusieurs milliers de résultats triés, en moins d'une
seconde.
Le problème s'aggrave encore quand on a une base avec un minimum de
redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
produit et ne pas celui du groupe de produits ou d'un domaine d'affaires,
qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
requêtes en mettant ces rubriques dans les lignes de commandes. Mais c'est
ça le but de données relationnelles?
En ce qui concerne les filtres, je préfère les requêtes d'abord parce
travaille sur une copie des données en local (question réseau). Mais aussi
parce que cela me donne plus de flexibilité pour les liaisons et rend
les rubriques triable, sans index.
Merci pour l'info. On en a déjà parlé l'année passée et j'avais vérifié à
l'époque que j'avais des index sur toutes mes rubriques de liaison et de
tri. Je les ai encore controllé maintenant.
Il y a toujours des rapports sur le NG de PCS de lenteurs avec la 8
(qui devrait être encore optimisé) et dans un exemple, quelqu'un
(probablement un collaborateur anonyme) a confirmé que la fonction TOP
provoquait des ralentissements... Je ne crois pas être trop paresseux de
chercher une solution et j'utilise des requêtes depuis 15 ans sans avoir
de gros problèmes. Ce n'était vraiment pas extravagant de relier pour nos
tests les fichiers de commandes/lignes, clients et articles, et trier par
date et numéro de commande (tous les clés indéxés).
Avec Windev en un an de travail, j'ai passée des journées entières pour la
recherche d'optimisations, sans pour autant trouver une solution valable
généralement. Ne faisant non plus confiance à moi seul, j'ai travaillé
dessus avec un spécialiste de SQL. Pour l'instant je n'ai jamais lu que
quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
en réseau, avec plusieurs milliers de résultats triés, en moins d'une
seconde. Le problème s'aggrave encore quand on a une base avec un minimum
redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
produit et ne pas celui du groupe de produits ou d'un domaine d'affaires,
qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
requêtes en mettant ces rubriques dans les lignes de commandes. Mais c'est
ça le but de données relationnelles?
En ce qui concerne les filtres, je préfère les requêtes d'abord parce
travaille sur une copie des données en local (question réseau). Mais aussi
parce que cela me donne plus de flexibilité pour les liaisons et rend
les rubriques triable, sans index.
"spetb" wrote in message
news:c17o3l$dhr$
> > En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
> version
> > 206g. Il n'y a plus les ralentissements lors d'accès
> Par
> > contre, la rapidité est toujours nettement inférieure aux requêtes de
> Visual
> > Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
> > tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
> lieu
> > de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
> Ghz).
> > Cela dépend biensûr aussi du matériel.
> > Le facteur principal de la lenteur des requêtes Windev / HF est que
> les
> > enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de
tri
> > et calcul sur le résultat Windev est plus rapide puisque la lecture
> > complété en arrière plan. Il y a des gens qui disent que la 8 est plus
> > rapide, d'autres disent que c'est toujours lent. Aussi longtemps que
> > résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
> pour
> > des gens soucieux de rapidité.
>
> Bonjour,
>
> Pour avoir une vitesse quasi instantanée pour des requetes sur des
fichiers
> HF, il faut que tous les champs de fichier concernés par la requete
> indexés, faites l'essai et vous serez surpris. Les résultats sont très
> voisins dans ce cas de ceux de VFP.
> Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
> filtres sur les fichiers HF, sur de très gros fichiers c'est encore plus
> rapide, par contre ces filtres sont un peu plus difficiles à programmer
que
> les requetes, mais quand on pratique un peu cela devient vite assez
évident.
>
> Sincères Salutations
> --
> Jean-Claude FLAJOULOT
> Sécurité Pointage & Biométrie
>
> (Otez _no_spam pour me contacter en PV)
>
> http://perso.wanadoo.fr/securite.pointage.et.biometrie/
>
>
Merci pour l'info. On en a déjà parlé l'année passée et j'avais vérifié à
l'époque que j'avais des index sur toutes mes rubriques de liaison et de
tri. Je les ai encore controllé maintenant.
Il y a toujours des rapports sur le NG de PCS de lenteurs avec la 8
(qui devrait être encore optimisé) et dans un exemple, quelqu'un
(probablement un collaborateur anonyme) a confirmé que la fonction TOP
provoquait des ralentissements... Je ne crois pas être trop paresseux de
chercher une solution et j'utilise des requêtes depuis 15 ans sans avoir
de gros problèmes. Ce n'était vraiment pas extravagant de relier pour nos
tests les fichiers de commandes/lignes, clients et articles, et trier par
date et numéro de commande (tous les clés indéxés).
Avec Windev en un an de travail, j'ai passée des journées entières pour la
recherche d'optimisations, sans pour autant trouver une solution valable
généralement. Ne faisant non plus confiance à moi seul, j'ai travaillé
dessus avec un spécialiste de SQL. Pour l'instant je n'ai jamais lu que
quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
en réseau, avec plusieurs milliers de résultats triés, en moins d'une
seconde. Le problème s'aggrave encore quand on a une base avec un minimum
redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
produit et ne pas celui du groupe de produits ou d'un domaine d'affaires,
qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
requêtes en mettant ces rubriques dans les lignes de commandes. Mais c'est
ça le but de données relationnelles?
En ce qui concerne les filtres, je préfère les requêtes d'abord parce
travaille sur une copie des données en local (question réseau). Mais aussi
parce que cela me donne plus de flexibilité pour les liaisons et rend
les rubriques triable, sans index.
"spetb" <spetb@wanadoo.fr> wrote in message
news:c17o3l$dhr$1@news-reader4.wanadoo.fr...
> > En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
> version
> > 206g. Il n'y a plus les ralentissements lors d'accès
> Par
> > contre, la rapidité est toujours nettement inférieure aux requêtes de
> Visual
> > Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
> > tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
> lieu
> > de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
> Ghz).
> > Cela dépend biensûr aussi du matériel.
> > Le facteur principal de la lenteur des requêtes Windev / HF est que
> les
> > enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de
tri
> > et calcul sur le résultat Windev est plus rapide puisque la lecture
> > complété en arrière plan. Il y a des gens qui disent que la 8 est plus
> > rapide, d'autres disent que c'est toujours lent. Aussi longtemps que
> > résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
> pour
> > des gens soucieux de rapidité.
>
> Bonjour,
>
> Pour avoir une vitesse quasi instantanée pour des requetes sur des
fichiers
> HF, il faut que tous les champs de fichier concernés par la requete
> indexés, faites l'essai et vous serez surpris. Les résultats sont très
> voisins dans ce cas de ceux de VFP.
> Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
> filtres sur les fichiers HF, sur de très gros fichiers c'est encore plus
> rapide, par contre ces filtres sont un peu plus difficiles à programmer
que
> les requetes, mais quand on pratique un peu cela devient vite assez
évident.
>
> Sincères Salutations
> --
> Jean-Claude FLAJOULOT
> Sécurité Pointage & Biométrie
> SPetB_no_spam@wandoo.fr
> (Otez _no_spam pour me contacter en PV)
>
> http://perso.wanadoo.fr/securite.pointage.et.biometrie/
>
>
Merci pour l'info. On en a déjà parlé l'année passée et j'avais vérifié à
l'époque que j'avais des index sur toutes mes rubriques de liaison et de
tri. Je les ai encore controllé maintenant.
Il y a toujours des rapports sur le NG de PCS de lenteurs avec la 8
(qui devrait être encore optimisé) et dans un exemple, quelqu'un
(probablement un collaborateur anonyme) a confirmé que la fonction TOP
provoquait des ralentissements... Je ne crois pas être trop paresseux de
chercher une solution et j'utilise des requêtes depuis 15 ans sans avoir
de gros problèmes. Ce n'était vraiment pas extravagant de relier pour nos
tests les fichiers de commandes/lignes, clients et articles, et trier par
date et numéro de commande (tous les clés indéxés).
Avec Windev en un an de travail, j'ai passée des journées entières pour la
recherche d'optimisations, sans pour autant trouver une solution valable
généralement. Ne faisant non plus confiance à moi seul, j'ai travaillé
dessus avec un spécialiste de SQL. Pour l'instant je n'ai jamais lu que
quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
en réseau, avec plusieurs milliers de résultats triés, en moins d'une
seconde. Le problème s'aggrave encore quand on a une base avec un minimum
redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
produit et ne pas celui du groupe de produits ou d'un domaine d'affaires,
qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
requêtes en mettant ces rubriques dans les lignes de commandes. Mais c'est
ça le but de données relationnelles?
En ce qui concerne les filtres, je préfère les requêtes d'abord parce
travaille sur une copie des données en local (question réseau). Mais aussi
parce que cela me donne plus de flexibilité pour les liaisons et rend
les rubriques triable, sans index.
"spetb" wrote in message
news:c17o3l$dhr$
> > En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
> version
> > 206g. Il n'y a plus les ralentissements lors d'accès
> Par
> > contre, la rapidité est toujours nettement inférieure aux requêtes de
> Visual
> > Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
> > tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
> lieu
> > de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
> Ghz).
> > Cela dépend biensûr aussi du matériel.
> > Le facteur principal de la lenteur des requêtes Windev / HF est que
> les
> > enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de
tri
> > et calcul sur le résultat Windev est plus rapide puisque la lecture
> > complété en arrière plan. Il y a des gens qui disent que la 8 est plus
> > rapide, d'autres disent que c'est toujours lent. Aussi longtemps que
> > résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
> pour
> > des gens soucieux de rapidité.
>
> Bonjour,
>
> Pour avoir une vitesse quasi instantanée pour des requetes sur des
fichiers
> HF, il faut que tous les champs de fichier concernés par la requete
> indexés, faites l'essai et vous serez surpris. Les résultats sont très
> voisins dans ce cas de ceux de VFP.
> Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
> filtres sur les fichiers HF, sur de très gros fichiers c'est encore plus
> rapide, par contre ces filtres sont un peu plus difficiles à programmer
que
> les requetes, mais quand on pratique un peu cela devient vite assez
évident.
>
> Sincères Salutations
> --
> Jean-Claude FLAJOULOT
> Sécurité Pointage & Biométrie
>
> (Otez _no_spam pour me contacter en PV)
>
> http://perso.wanadoo.fr/securite.pointage.et.biometrie/
>
>
Merci pour l'info. On en a déjà parlé l'année passée et j'avais vérifié à
l'époque que j'avais des index sur toutes mes rubriques de liaison et de
tri. Je les ai encore controllé maintenant.
Il y a toujours des rapports sur le NG de PCS de lenteurs avec la 8
(qui devrait être encore optimisé) et dans un exemple, quelqu'un
(probablement un collaborateur anonyme) a confirmé que la fonction TOP
provoquait des ralentissements... Je ne crois pas être trop paresseux de
chercher une solution et j'utilise des requêtes depuis 15 ans sans avoir
de gros problèmes. Ce n'était vraiment pas extravagant de relier pour nos
tests les fichiers de commandes/lignes, clients et articles, et trier par
date et numéro de commande (tous les clés indéxés).
Avec Windev en un an de travail, j'ai passée des journées entières pour la
recherche d'optimisations, sans pour autant trouver une solution valable
généralement. Ne faisant non plus confiance à moi seul, j'ai travaillé
dessus avec un spécialiste de SQL. Pour l'instant je n'ai jamais lu que
quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
en réseau, avec plusieurs milliers de résultats triés, en moins d'une
seconde. Le problème s'aggrave encore quand on a une base avec un minimum
redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
produit et ne pas celui du groupe de produits ou d'un domaine d'affaires,
qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
requêtes en mettant ces rubriques dans les lignes de commandes. Mais c'est
ça le but de données relationnelles?
En ce qui concerne les filtres, je préfère les requêtes d'abord parce
travaille sur une copie des données en local (question réseau). Mais aussi
parce que cela me donne plus de flexibilité pour les liaisons et rend
les rubriques triable, sans index.
"spetb" wrote in message
news:c17o3l$dhr$
> > En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
> version
> > 206g. Il n'y a plus les ralentissements lors d'accès
> Par
> > contre, la rapidité est toujours nettement inférieure aux requêtes de
> Visual
> > Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
> > tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
> lieu
> > de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
> Ghz).
> > Cela dépend biensûr aussi du matériel.
> > Le facteur principal de la lenteur des requêtes Windev / HF est que
> les
> > enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de
tri
> > et calcul sur le résultat Windev est plus rapide puisque la lecture
> > complété en arrière plan. Il y a des gens qui disent que la 8 est plus
> > rapide, d'autres disent que c'est toujours lent. Aussi longtemps que
> > résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
> pour
> > des gens soucieux de rapidité.
>
> Bonjour,
>
> Pour avoir une vitesse quasi instantanée pour des requetes sur des
fichiers
> HF, il faut que tous les champs de fichier concernés par la requete
> indexés, faites l'essai et vous serez surpris. Les résultats sont très
> voisins dans ce cas de ceux de VFP.
> Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
> filtres sur les fichiers HF, sur de très gros fichiers c'est encore plus
> rapide, par contre ces filtres sont un peu plus difficiles à programmer
que
> les requetes, mais quand on pratique un peu cela devient vite assez
évident.
>
> Sincères Salutations
> --
> Jean-Claude FLAJOULOT
> Sécurité Pointage & Biométrie
>
> (Otez _no_spam pour me contacter en PV)
>
> http://perso.wanadoo.fr/securite.pointage.et.biometrie/
>
>
Merci pour l'info. On en a déjà parlé l'année passée et j'avais vérifié à
l'époque que j'avais des index sur toutes mes rubriques de liaison et de
tri. Je les ai encore controllé maintenant.
Il y a toujours des rapports sur le NG de PCS de lenteurs avec la 8
(qui devrait être encore optimisé) et dans un exemple, quelqu'un
(probablement un collaborateur anonyme) a confirmé que la fonction TOP
provoquait des ralentissements... Je ne crois pas être trop paresseux de
chercher une solution et j'utilise des requêtes depuis 15 ans sans avoir
de gros problèmes. Ce n'était vraiment pas extravagant de relier pour nos
tests les fichiers de commandes/lignes, clients et articles, et trier par
date et numéro de commande (tous les clés indéxés).
Avec Windev en un an de travail, j'ai passée des journées entières pour la
recherche d'optimisations, sans pour autant trouver une solution valable
généralement. Ne faisant non plus confiance à moi seul, j'ai travaillé
dessus avec un spécialiste de SQL. Pour l'instant je n'ai jamais lu que
quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
en réseau, avec plusieurs milliers de résultats triés, en moins d'une
seconde. Le problème s'aggrave encore quand on a une base avec un minimum
redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
produit et ne pas celui du groupe de produits ou d'un domaine d'affaires,
qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
requêtes en mettant ces rubriques dans les lignes de commandes. Mais c'est
ça le but de données relationnelles?
En ce qui concerne les filtres, je préfère les requêtes d'abord parce
travaille sur une copie des données en local (question réseau). Mais aussi
parce que cela me donne plus de flexibilité pour les liaisons et rend
les rubriques triable, sans index.
"spetb" <spetb@wanadoo.fr> wrote in message
news:c17o3l$dhr$1@news-reader4.wanadoo.fr...
> > En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
> version
> > 206g. Il n'y a plus les ralentissements lors d'accès
> Par
> > contre, la rapidité est toujours nettement inférieure aux requêtes de
> Visual
> > Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
> > tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
> lieu
> > de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
> Ghz).
> > Cela dépend biensûr aussi du matériel.
> > Le facteur principal de la lenteur des requêtes Windev / HF est que
> les
> > enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de
tri
> > et calcul sur le résultat Windev est plus rapide puisque la lecture
> > complété en arrière plan. Il y a des gens qui disent que la 8 est plus
> > rapide, d'autres disent que c'est toujours lent. Aussi longtemps que
> > résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
> pour
> > des gens soucieux de rapidité.
>
> Bonjour,
>
> Pour avoir une vitesse quasi instantanée pour des requetes sur des
fichiers
> HF, il faut que tous les champs de fichier concernés par la requete
> indexés, faites l'essai et vous serez surpris. Les résultats sont très
> voisins dans ce cas de ceux de VFP.
> Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
> filtres sur les fichiers HF, sur de très gros fichiers c'est encore plus
> rapide, par contre ces filtres sont un peu plus difficiles à programmer
que
> les requetes, mais quand on pratique un peu cela devient vite assez
évident.
>
> Sincères Salutations
> --
> Jean-Claude FLAJOULOT
> Sécurité Pointage & Biométrie
> SPetB_no_spam@wandoo.fr
> (Otez _no_spam pour me contacter en PV)
>
> http://perso.wanadoo.fr/securite.pointage.et.biometrie/
>
>
Merci pour l'info. On en a déjà parlé l'année passée et j'avais vérifié à
l'époque que j'avais des index sur toutes mes rubriques de liaison et de
tri. Je les ai encore controllé maintenant.
Il y a toujours des rapports sur le NG de PCS de lenteurs avec la 8
(qui devrait être encore optimisé) et dans un exemple, quelqu'un
(probablement un collaborateur anonyme) a confirmé que la fonction TOP
provoquait des ralentissements... Je ne crois pas être trop paresseux de
chercher une solution et j'utilise des requêtes depuis 15 ans sans avoir
de gros problèmes. Ce n'était vraiment pas extravagant de relier pour nos
tests les fichiers de commandes/lignes, clients et articles, et trier par
date et numéro de commande (tous les clés indéxés).
Avec Windev en un an de travail, j'ai passée des journées entières pour la
recherche d'optimisations, sans pour autant trouver une solution valable
généralement. Ne faisant non plus confiance à moi seul, j'ai travaillé
dessus avec un spécialiste de SQL. Pour l'instant je n'ai jamais lu que
quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
en réseau, avec plusieurs milliers de résultats triés, en moins d'une
seconde. Le problème s'aggrave encore quand on a une base avec un minimum
redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
produit et ne pas celui du groupe de produits ou d'un domaine d'affaires,
qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
requêtes en mettant ces rubriques dans les lignes de commandes. Mais c'est
ça le but de données relationnelles?
En ce qui concerne les filtres, je préfère les requêtes d'abord parce
travaille sur une copie des données en local (question réseau). Mais aussi
parce que cela me donne plus de flexibilité pour les liaisons et rend
les rubriques triable, sans index.
"spetb" wrote in message
news:c17o3l$dhr$
> > En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
> version
> > 206g. Il n'y a plus les ralentissements lors d'accès
> Par
> > contre, la rapidité est toujours nettement inférieure aux requêtes de
> Visual
> > Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de nos
> > tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes au
> lieu
> > de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines < 1
> Ghz).
> > Cela dépend biensûr aussi du matériel.
> > Le facteur principal de la lenteur des requêtes Windev / HF est que
> les
> > enregistrements du résultat sont lus en mémoire. Quand il n'y a pas de
tri
> > et calcul sur le résultat Windev est plus rapide puisque la lecture
> > complété en arrière plan. Il y a des gens qui disent que la 8 est plus
> > rapide, d'autres disent que c'est toujours lent. Aussi longtemps que
> > résultats des requêtes sont lus en mémoire, je déconseille Windev / HF
> pour
> > des gens soucieux de rapidité.
>
> Bonjour,
>
> Pour avoir une vitesse quasi instantanée pour des requetes sur des
fichiers
> HF, il faut que tous les champs de fichier concernés par la requete
> indexés, faites l'essai et vous serez surpris. Les résultats sont très
> voisins dans ce cas de ceux de VFP.
> Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
> filtres sur les fichiers HF, sur de très gros fichiers c'est encore plus
> rapide, par contre ces filtres sont un peu plus difficiles à programmer
que
> les requetes, mais quand on pratique un peu cela devient vite assez
évident.
>
> Sincères Salutations
> --
> Jean-Claude FLAJOULOT
> Sécurité Pointage & Biométrie
>
> (Otez _no_spam pour me contacter en PV)
>
> http://perso.wanadoo.fr/securite.pointage.et.biometrie/
>
>
Merci beaucoup pour vos réponses très pertinentes.
J'apprécie vraiment beaucoup de partager vos expériences et cela confirme
mes craintes - mais c'est ce que je désirais, du vécu objectif avec les
performances de Windev.
Je ne veux entrer en compétition avec personne - vous qui avez passé
beaucoup de temps à tenter d'optimiser les performance des requêtes de
Windev mais j'aimerais vous soumettre le résultat de certains tests
d'optimisation que j'ai fait avec le SQL de FoxPro et qui s'applique
peut-être aussi à Windev.
Étant relativement critique sur les performances, j'ai fait de nombreux
tests avec SQL quand il a été disponible avec FoxPro.
A tord ou à raison, et étant de la vieille école, je ne faisais pas tout à
fait confiance aux requêtes complexes SQL et j'avais des doutes à lui
confier une optimisation maximale. Mais j'aime beaucoup le concept et la
performance est en général excellente.
Des requêtes complexes, j'en ai fait plusieurs mais je me suis rendu
que rien ne valait mon expérience et mon jugement combiné à SQL au lieu de
lui soumettre aveuglément une requête complexe et espérer que dans tous
cas l'optimisation serait optimale.
Je m'explique avec un simple exemple. Ce n'est peut-être pas la meilleure,
mais ça donne un idée du concept.
Supposons une recherche des ventes d'une période de 3 mois, par catégories
et par clients dans un journal des ventes de 10 ans cumulés.
Si la base de donnée n'est jamais appelée à devenir immense - selon mon
expérience - ma requête SQL sera directe en une seule commande.
Mais si la base est ou sera éventuellement très volumineuse, je décortique
les ordres SQL.
Par exemple, un première requête ira seulement chercher les 3 mois de
et les placera dans un fichier temporaire.
Je travaille ensuite avec ce fichier temporaire qui est considérablement
plus petit.
FoxPro mentionne qu'un fichier temporaire est placé automatiquement par
défaut dans la mémoire cache et s'il manque de place seulement il le place
sur le disque dur. Il mentionne même que certains fichiers temporaires ne
sont jamais écrit sur disque. Sachant que la mémoire cache est
considérablement plus rapide qu'un disque dur, je savais que j'accélérait
par le fait même ma requête.
Au besoin je fais plusieurs requêtes successives (parfois 4 ou 5) en
bien soin de fermer chaque fichier temporaire précédent dès que j'en ai
terminé, libérant ainsi la mémoire. FoxPro efface automatiquement un
temporaire dès sa fermeture.
J'espère que je m'explique bien.
En fait, c'est qu'au lieu de faire une confiance aveugle à SQL qui est
optimiser ses recherches, je le fait pour lui.
C'est un peu plus de lignes de codes mais c'est par contre souvent plus
facile à comprendre 3 ans plus tard quand on a à faire la maintenance sur
code qu'on a pas touché depuis longtemps.
Dans le cas du TOP 20 - maintenant que je sais que cela ralentit le
processus SQL en Windev - je ferais la recherche sans TOP et place le
résultat dans un fichier temporaire en classant le résultat en DESC et je
vais chercher les 20 premiers dans une autre opération.
Je présume que c'est ce que font plusieurs - mais je ne serais pas étonné
que de nombreux utilisateurs Windev subissent le ralentissement sans
chercher de solution.
Dans FoxPro, j'ai vu de bonnes différences de vitesse dans plusieurs cas.
Je sais qu'à la base, la vitesse de manipulation des fichiers Windev est
plus lente qu'en Fox mais
quelqu'un a-t-il essayé en Windev la méthode que je mentionne ci-dessus?
résultats sont-ils de beaucoup améliorés?
Cordialement,
Réal Philippon
Programmation Ultra Ltée -o- www.ultra.ca
L'informatique sur mesure depuis plus de 24 ans
"mat" a écrit dans le message de
news:c187gc$1fr9r8$
> Merci pour l'info. On en a déjà parlé l'année passée et j'avais vérifié
> l'époque que j'avais des index sur toutes mes rubriques de liaison et de
> tri. Je les ai encore controllé maintenant.
>
> Il y a toujours des rapports sur le NG de PCS de lenteurs avec la 8
> (qui devrait être encore optimisé) et dans un exemple, quelqu'un
> (probablement un collaborateur anonyme) a confirmé que la fonction TOP
> provoquait des ralentissements... Je ne crois pas être trop paresseux de
> chercher une solution et j'utilise des requêtes depuis 15 ans sans avoir
eu
> de gros problèmes. Ce n'était vraiment pas extravagant de relier pour
> tests les fichiers de commandes/lignes, clients et articles, et trier
> date et numéro de commande (tous les clés indéxés).
>
> Avec Windev en un an de travail, j'ai passée des journées entières pour
> recherche d'optimisations, sans pour autant trouver une solution valable
> généralement. Ne faisant non plus confiance à moi seul, j'ai travaillé
> dessus avec un spécialiste de SQL. Pour l'instant je n'ai jamais lu que
> quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
fichiers
> en réseau, avec plusieurs milliers de résultats triés, en moins d'une
> seconde. Le problème s'aggrave encore quand on a une base avec un
de
> redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
> produit et ne pas celui du groupe de produits ou d'un domaine
ce
> qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
les
> requêtes en mettant ces rubriques dans les lignes de commandes. Mais
> ça le but de données relationnelles?
>
> En ce qui concerne les filtres, je préfère les requêtes d'abord parce
qu'on
> travaille sur une copie des données en local (question réseau). Mais
> parce que cela me donne plus de flexibilité pour les liaisons et rend
toutes
> les rubriques triable, sans index.
>
>
> "spetb" wrote in message
> news:c17o3l$dhr$
> > > En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
> > version
> > > 206g. Il n'y a plus les ralentissements lors d'accès
multi-utilisateurs.
> > Par
> > > contre, la rapidité est toujours nettement inférieure aux requêtes
> > Visual
> > > Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de
> > > tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes
> > lieu
> > > de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines <
> > Ghz).
> > > Cela dépend biensûr aussi du matériel.
> > > Le facteur principal de la lenteur des requêtes Windev / HF est que
tous
> > les
> > > enregistrements du résultat sont lus en mémoire. Quand il n'y a pas
> tri
> > > et calcul sur le résultat Windev est plus rapide puisque la lecture
est
> > > complété en arrière plan. Il y a des gens qui disent que la 8 est
> > > rapide, d'autres disent que c'est toujours lent. Aussi longtemps que
les
> > > résultats des requêtes sont lus en mémoire, je déconseille Windev /
> > pour
> > > des gens soucieux de rapidité.
> >
> > Bonjour,
> >
> > Pour avoir une vitesse quasi instantanée pour des requetes sur des
> fichiers
> > HF, il faut que tous les champs de fichier concernés par la requete
soient
> > indexés, faites l'essai et vous serez surpris. Les résultats sont très
> > voisins dans ce cas de ceux de VFP.
> > Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
> > filtres sur les fichiers HF, sur de très gros fichiers c'est encore
> > rapide, par contre ces filtres sont un peu plus difficiles à
> que
> > les requetes, mais quand on pratique un peu cela devient vite assez
> évident.
> >
> > Sincères Salutations
> > --
> > Jean-Claude FLAJOULOT
> > Sécurité Pointage & Biométrie
> >
> > (Otez _no_spam pour me contacter en PV)
> >
> > http://perso.wanadoo.fr/securite.pointage.et.biometrie/
> >
> >
>
>
>
Merci beaucoup pour vos réponses très pertinentes.
J'apprécie vraiment beaucoup de partager vos expériences et cela confirme
mes craintes - mais c'est ce que je désirais, du vécu objectif avec les
performances de Windev.
Je ne veux entrer en compétition avec personne - vous qui avez passé
beaucoup de temps à tenter d'optimiser les performance des requêtes de
Windev mais j'aimerais vous soumettre le résultat de certains tests
d'optimisation que j'ai fait avec le SQL de FoxPro et qui s'applique
peut-être aussi à Windev.
Étant relativement critique sur les performances, j'ai fait de nombreux
tests avec SQL quand il a été disponible avec FoxPro.
A tord ou à raison, et étant de la vieille école, je ne faisais pas tout à
fait confiance aux requêtes complexes SQL et j'avais des doutes à lui
confier une optimisation maximale. Mais j'aime beaucoup le concept et la
performance est en général excellente.
Des requêtes complexes, j'en ai fait plusieurs mais je me suis rendu
que rien ne valait mon expérience et mon jugement combiné à SQL au lieu de
lui soumettre aveuglément une requête complexe et espérer que dans tous
cas l'optimisation serait optimale.
Je m'explique avec un simple exemple. Ce n'est peut-être pas la meilleure,
mais ça donne un idée du concept.
Supposons une recherche des ventes d'une période de 3 mois, par catégories
et par clients dans un journal des ventes de 10 ans cumulés.
Si la base de donnée n'est jamais appelée à devenir immense - selon mon
expérience - ma requête SQL sera directe en une seule commande.
Mais si la base est ou sera éventuellement très volumineuse, je décortique
les ordres SQL.
Par exemple, un première requête ira seulement chercher les 3 mois de
et les placera dans un fichier temporaire.
Je travaille ensuite avec ce fichier temporaire qui est considérablement
plus petit.
FoxPro mentionne qu'un fichier temporaire est placé automatiquement par
défaut dans la mémoire cache et s'il manque de place seulement il le place
sur le disque dur. Il mentionne même que certains fichiers temporaires ne
sont jamais écrit sur disque. Sachant que la mémoire cache est
considérablement plus rapide qu'un disque dur, je savais que j'accélérait
par le fait même ma requête.
Au besoin je fais plusieurs requêtes successives (parfois 4 ou 5) en
bien soin de fermer chaque fichier temporaire précédent dès que j'en ai
terminé, libérant ainsi la mémoire. FoxPro efface automatiquement un
temporaire dès sa fermeture.
J'espère que je m'explique bien.
En fait, c'est qu'au lieu de faire une confiance aveugle à SQL qui est
optimiser ses recherches, je le fait pour lui.
C'est un peu plus de lignes de codes mais c'est par contre souvent plus
facile à comprendre 3 ans plus tard quand on a à faire la maintenance sur
code qu'on a pas touché depuis longtemps.
Dans le cas du TOP 20 - maintenant que je sais que cela ralentit le
processus SQL en Windev - je ferais la recherche sans TOP et place le
résultat dans un fichier temporaire en classant le résultat en DESC et je
vais chercher les 20 premiers dans une autre opération.
Je présume que c'est ce que font plusieurs - mais je ne serais pas étonné
que de nombreux utilisateurs Windev subissent le ralentissement sans
chercher de solution.
Dans FoxPro, j'ai vu de bonnes différences de vitesse dans plusieurs cas.
Je sais qu'à la base, la vitesse de manipulation des fichiers Windev est
plus lente qu'en Fox mais
quelqu'un a-t-il essayé en Windev la méthode que je mentionne ci-dessus?
résultats sont-ils de beaucoup améliorés?
Cordialement,
Réal Philippon
Programmation Ultra Ltée -o- www.ultra.ca
L'informatique sur mesure depuis plus de 24 ans
"mat" <mnobs@bluemail.ch> a écrit dans le message de
news:c187gc$1fr9r8$1@ID-225718.news.uni-berlin.de...
> Merci pour l'info. On en a déjà parlé l'année passée et j'avais vérifié
> l'époque que j'avais des index sur toutes mes rubriques de liaison et de
> tri. Je les ai encore controllé maintenant.
>
> Il y a toujours des rapports sur le NG de PCS de lenteurs avec la 8
> (qui devrait être encore optimisé) et dans un exemple, quelqu'un
> (probablement un collaborateur anonyme) a confirmé que la fonction TOP
> provoquait des ralentissements... Je ne crois pas être trop paresseux de
> chercher une solution et j'utilise des requêtes depuis 15 ans sans avoir
eu
> de gros problèmes. Ce n'était vraiment pas extravagant de relier pour
> tests les fichiers de commandes/lignes, clients et articles, et trier
> date et numéro de commande (tous les clés indéxés).
>
> Avec Windev en un an de travail, j'ai passée des journées entières pour
> recherche d'optimisations, sans pour autant trouver une solution valable
> généralement. Ne faisant non plus confiance à moi seul, j'ai travaillé
> dessus avec un spécialiste de SQL. Pour l'instant je n'ai jamais lu que
> quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
fichiers
> en réseau, avec plusieurs milliers de résultats triés, en moins d'une
> seconde. Le problème s'aggrave encore quand on a une base avec un
de
> redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
> produit et ne pas celui du groupe de produits ou d'un domaine
ce
> qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
les
> requêtes en mettant ces rubriques dans les lignes de commandes. Mais
> ça le but de données relationnelles?
>
> En ce qui concerne les filtres, je préfère les requêtes d'abord parce
qu'on
> travaille sur une copie des données en local (question réseau). Mais
> parce que cela me donne plus de flexibilité pour les liaisons et rend
toutes
> les rubriques triable, sans index.
>
>
> "spetb" <spetb@wanadoo.fr> wrote in message
> news:c17o3l$dhr$1@news-reader4.wanadoo.fr...
> > > En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
> > version
> > > 206g. Il n'y a plus les ralentissements lors d'accès
multi-utilisateurs.
> > Par
> > > contre, la rapidité est toujours nettement inférieure aux requêtes
> > Visual
> > > Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de
> > > tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes
> > lieu
> > > de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines <
> > Ghz).
> > > Cela dépend biensûr aussi du matériel.
> > > Le facteur principal de la lenteur des requêtes Windev / HF est que
tous
> > les
> > > enregistrements du résultat sont lus en mémoire. Quand il n'y a pas
> tri
> > > et calcul sur le résultat Windev est plus rapide puisque la lecture
est
> > > complété en arrière plan. Il y a des gens qui disent que la 8 est
> > > rapide, d'autres disent que c'est toujours lent. Aussi longtemps que
les
> > > résultats des requêtes sont lus en mémoire, je déconseille Windev /
> > pour
> > > des gens soucieux de rapidité.
> >
> > Bonjour,
> >
> > Pour avoir une vitesse quasi instantanée pour des requetes sur des
> fichiers
> > HF, il faut que tous les champs de fichier concernés par la requete
soient
> > indexés, faites l'essai et vous serez surpris. Les résultats sont très
> > voisins dans ce cas de ceux de VFP.
> > Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
> > filtres sur les fichiers HF, sur de très gros fichiers c'est encore
> > rapide, par contre ces filtres sont un peu plus difficiles à
> que
> > les requetes, mais quand on pratique un peu cela devient vite assez
> évident.
> >
> > Sincères Salutations
> > --
> > Jean-Claude FLAJOULOT
> > Sécurité Pointage & Biométrie
> > SPetB_no_spam@wandoo.fr
> > (Otez _no_spam pour me contacter en PV)
> >
> > http://perso.wanadoo.fr/securite.pointage.et.biometrie/
> >
> >
>
>
>
Merci beaucoup pour vos réponses très pertinentes.
J'apprécie vraiment beaucoup de partager vos expériences et cela confirme
mes craintes - mais c'est ce que je désirais, du vécu objectif avec les
performances de Windev.
Je ne veux entrer en compétition avec personne - vous qui avez passé
beaucoup de temps à tenter d'optimiser les performance des requêtes de
Windev mais j'aimerais vous soumettre le résultat de certains tests
d'optimisation que j'ai fait avec le SQL de FoxPro et qui s'applique
peut-être aussi à Windev.
Étant relativement critique sur les performances, j'ai fait de nombreux
tests avec SQL quand il a été disponible avec FoxPro.
A tord ou à raison, et étant de la vieille école, je ne faisais pas tout à
fait confiance aux requêtes complexes SQL et j'avais des doutes à lui
confier une optimisation maximale. Mais j'aime beaucoup le concept et la
performance est en général excellente.
Des requêtes complexes, j'en ai fait plusieurs mais je me suis rendu
que rien ne valait mon expérience et mon jugement combiné à SQL au lieu de
lui soumettre aveuglément une requête complexe et espérer que dans tous
cas l'optimisation serait optimale.
Je m'explique avec un simple exemple. Ce n'est peut-être pas la meilleure,
mais ça donne un idée du concept.
Supposons une recherche des ventes d'une période de 3 mois, par catégories
et par clients dans un journal des ventes de 10 ans cumulés.
Si la base de donnée n'est jamais appelée à devenir immense - selon mon
expérience - ma requête SQL sera directe en une seule commande.
Mais si la base est ou sera éventuellement très volumineuse, je décortique
les ordres SQL.
Par exemple, un première requête ira seulement chercher les 3 mois de
et les placera dans un fichier temporaire.
Je travaille ensuite avec ce fichier temporaire qui est considérablement
plus petit.
FoxPro mentionne qu'un fichier temporaire est placé automatiquement par
défaut dans la mémoire cache et s'il manque de place seulement il le place
sur le disque dur. Il mentionne même que certains fichiers temporaires ne
sont jamais écrit sur disque. Sachant que la mémoire cache est
considérablement plus rapide qu'un disque dur, je savais que j'accélérait
par le fait même ma requête.
Au besoin je fais plusieurs requêtes successives (parfois 4 ou 5) en
bien soin de fermer chaque fichier temporaire précédent dès que j'en ai
terminé, libérant ainsi la mémoire. FoxPro efface automatiquement un
temporaire dès sa fermeture.
J'espère que je m'explique bien.
En fait, c'est qu'au lieu de faire une confiance aveugle à SQL qui est
optimiser ses recherches, je le fait pour lui.
C'est un peu plus de lignes de codes mais c'est par contre souvent plus
facile à comprendre 3 ans plus tard quand on a à faire la maintenance sur
code qu'on a pas touché depuis longtemps.
Dans le cas du TOP 20 - maintenant que je sais que cela ralentit le
processus SQL en Windev - je ferais la recherche sans TOP et place le
résultat dans un fichier temporaire en classant le résultat en DESC et je
vais chercher les 20 premiers dans une autre opération.
Je présume que c'est ce que font plusieurs - mais je ne serais pas étonné
que de nombreux utilisateurs Windev subissent le ralentissement sans
chercher de solution.
Dans FoxPro, j'ai vu de bonnes différences de vitesse dans plusieurs cas.
Je sais qu'à la base, la vitesse de manipulation des fichiers Windev est
plus lente qu'en Fox mais
quelqu'un a-t-il essayé en Windev la méthode que je mentionne ci-dessus?
résultats sont-ils de beaucoup améliorés?
Cordialement,
Réal Philippon
Programmation Ultra Ltée -o- www.ultra.ca
L'informatique sur mesure depuis plus de 24 ans
"mat" a écrit dans le message de
news:c187gc$1fr9r8$
> Merci pour l'info. On en a déjà parlé l'année passée et j'avais vérifié
> l'époque que j'avais des index sur toutes mes rubriques de liaison et de
> tri. Je les ai encore controllé maintenant.
>
> Il y a toujours des rapports sur le NG de PCS de lenteurs avec la 8
> (qui devrait être encore optimisé) et dans un exemple, quelqu'un
> (probablement un collaborateur anonyme) a confirmé que la fonction TOP
> provoquait des ralentissements... Je ne crois pas être trop paresseux de
> chercher une solution et j'utilise des requêtes depuis 15 ans sans avoir
eu
> de gros problèmes. Ce n'était vraiment pas extravagant de relier pour
> tests les fichiers de commandes/lignes, clients et articles, et trier
> date et numéro de commande (tous les clés indéxés).
>
> Avec Windev en un an de travail, j'ai passée des journées entières pour
> recherche d'optimisations, sans pour autant trouver une solution valable
> généralement. Ne faisant non plus confiance à moi seul, j'ai travaillé
> dessus avec un spécialiste de SQL. Pour l'instant je n'ai jamais lu que
> quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
fichiers
> en réseau, avec plusieurs milliers de résultats triés, en moins d'une
> seconde. Le problème s'aggrave encore quand on a une base avec un
de
> redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
> produit et ne pas celui du groupe de produits ou d'un domaine
ce
> qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
les
> requêtes en mettant ces rubriques dans les lignes de commandes. Mais
> ça le but de données relationnelles?
>
> En ce qui concerne les filtres, je préfère les requêtes d'abord parce
qu'on
> travaille sur une copie des données en local (question réseau). Mais
> parce que cela me donne plus de flexibilité pour les liaisons et rend
toutes
> les rubriques triable, sans index.
>
>
> "spetb" wrote in message
> news:c17o3l$dhr$
> > > En 7.5 la situation s'est amélioré un peu pour les requêtes avec la
> > version
> > > 206g. Il n'y a plus les ralentissements lors d'accès
multi-utilisateurs.
> > Par
> > > contre, la rapidité est toujours nettement inférieure aux requêtes
> > Visual
> > > Foxpro. Pour les 2500 à 4200 enregistrements dans les résultats de
> > > tests, c'était à peu près 3 à 5 fois plus lent (env. 2 à 3 secondes
> > lieu
> > > de 0.5 à 1 seconde pour VFox, Delphi ou Paradox avec des machines <
> > Ghz).
> > > Cela dépend biensûr aussi du matériel.
> > > Le facteur principal de la lenteur des requêtes Windev / HF est que
tous
> > les
> > > enregistrements du résultat sont lus en mémoire. Quand il n'y a pas
> tri
> > > et calcul sur le résultat Windev est plus rapide puisque la lecture
est
> > > complété en arrière plan. Il y a des gens qui disent que la 8 est
> > > rapide, d'autres disent que c'est toujours lent. Aussi longtemps que
les
> > > résultats des requêtes sont lus en mémoire, je déconseille Windev /
> > pour
> > > des gens soucieux de rapidité.
> >
> > Bonjour,
> >
> > Pour avoir une vitesse quasi instantanée pour des requetes sur des
> fichiers
> > HF, il faut que tous les champs de fichier concernés par la requete
soient
> > indexés, faites l'essai et vous serez surpris. Les résultats sont très
> > voisins dans ce cas de ceux de VFP.
> > Nota : Personnellement n'étant pas un fan de SQL j'utilise plutot des
> > filtres sur les fichiers HF, sur de très gros fichiers c'est encore
> > rapide, par contre ces filtres sont un peu plus difficiles à
> que
> > les requetes, mais quand on pratique un peu cela devient vite assez
> évident.
> >
> > Sincères Salutations
> > --
> > Jean-Claude FLAJOULOT
> > Sécurité Pointage & Biométrie
> >
> > (Otez _no_spam pour me contacter en PV)
> >
> > http://perso.wanadoo.fr/securite.pointage.et.biometrie/
> >
> >
>
>
>
Bonsoir,
Désolé mais certaines réponses vont vous paraitre un peu cavalières de ma
part mais je pense qu'il fallait remettre un peu les idées en place pour
lecteurs peu coutumier de Windev.
> [CUT]
> Avec Windev en un an de travail, j'ai passée des journées entières pour
> recherche d'optimisations, sans pour autant trouver une solution valable
> généralement.
Des solutions coté base de données ou cote traitement ? Parce que 1 an
long ;-)
> Ne faisant non plus confiance à moi seul, j'ai travaillé
> dessus avec un spécialiste de SQL.
Un "spécialiste" de SQL t'aurait certainement conseillé de passé sur un
standard du marché (mais payant !)
> Pour l'instant je n'ai jamais lu que
> quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
fichiers
> en réseau, avec plusieurs milliers de résultats triés, en moins d'une
> seconde.
Désolé mais je ne connais que 2 SGBD capable de répondre à ton besoin en
terme de "une seconde" pour des volumétrie en milliers (et millions) :
TERADATA et DB2. Dans les 2 cas on n'est plus dans la même catégorie ! Je
travaille quotidiennement aussi bien avec DB2 que du Oracle et c'est vrai
que des tris, des requêtes avec plus de 5 tables en jointure c'est
faisable...
>Le problème s'aggrave encore quand on a une base avec un minimum de
> redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
> produit et ne pas celui du groupe de produits ou d'un domaine
ce
> qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
les
> requêtes en mettant ces rubriques dans les lignes de commandes. Mais
> ça le but de données relationnelles?
C'est l'inconvénient du SGBDR : à force de tout avoir en 3NF voire 4NF, on
se plaint des temps de réponses ! D'après toi pourquoi les SI-Décisionnels
utilisent la dénormalisation si ce n'est (en autre) par soucis de
Pour info pour certains SGBD les IN sont transformés en "...OR...OR", pour
certains SGBD il est préférable d'utiliser la commande EXIST que la
IN par contre il vaut mieux NOT IN que NOT EXIST. En gros chaque SGBD a
propre mode de fonctionnement coté interprétation de requete. Donc évitons
de comparer.
> En ce qui concerne les filtres, je préfère les requêtes d'abord parce
qu'on
> travaille sur une copie des données en local (question réseau). Mais
> parce que cela me donne plus de flexibilité pour les liaisons et rend
toutes
> les rubriques triable, sans index.
PC-Soft avait fourni une abaque pour le requetage sur les fichiers : en
fonction de la volumétrie on passe par tel ou tel mode de lecture (filtre,
vue, requete).
Emmanuel
Bonsoir,
Désolé mais certaines réponses vont vous paraitre un peu cavalières de ma
part mais je pense qu'il fallait remettre un peu les idées en place pour
lecteurs peu coutumier de Windev.
> [CUT]
> Avec Windev en un an de travail, j'ai passée des journées entières pour
> recherche d'optimisations, sans pour autant trouver une solution valable
> généralement.
Des solutions coté base de données ou cote traitement ? Parce que 1 an
long ;-)
> Ne faisant non plus confiance à moi seul, j'ai travaillé
> dessus avec un spécialiste de SQL.
Un "spécialiste" de SQL t'aurait certainement conseillé de passé sur un
standard du marché (mais payant !)
> Pour l'instant je n'ai jamais lu que
> quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
fichiers
> en réseau, avec plusieurs milliers de résultats triés, en moins d'une
> seconde.
Désolé mais je ne connais que 2 SGBD capable de répondre à ton besoin en
terme de "une seconde" pour des volumétrie en milliers (et millions) :
TERADATA et DB2. Dans les 2 cas on n'est plus dans la même catégorie ! Je
travaille quotidiennement aussi bien avec DB2 que du Oracle et c'est vrai
que des tris, des requêtes avec plus de 5 tables en jointure c'est
faisable...
>Le problème s'aggrave encore quand on a une base avec un minimum de
> redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
> produit et ne pas celui du groupe de produits ou d'un domaine
ce
> qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
les
> requêtes en mettant ces rubriques dans les lignes de commandes. Mais
> ça le but de données relationnelles?
C'est l'inconvénient du SGBDR : à force de tout avoir en 3NF voire 4NF, on
se plaint des temps de réponses ! D'après toi pourquoi les SI-Décisionnels
utilisent la dénormalisation si ce n'est (en autre) par soucis de
Pour info pour certains SGBD les IN sont transformés en "...OR...OR", pour
certains SGBD il est préférable d'utiliser la commande EXIST que la
IN par contre il vaut mieux NOT IN que NOT EXIST. En gros chaque SGBD a
propre mode de fonctionnement coté interprétation de requete. Donc évitons
de comparer.
> En ce qui concerne les filtres, je préfère les requêtes d'abord parce
qu'on
> travaille sur une copie des données en local (question réseau). Mais
> parce que cela me donne plus de flexibilité pour les liaisons et rend
toutes
> les rubriques triable, sans index.
PC-Soft avait fourni une abaque pour le requetage sur les fichiers : en
fonction de la volumétrie on passe par tel ou tel mode de lecture (filtre,
vue, requete).
Emmanuel
Bonsoir,
Désolé mais certaines réponses vont vous paraitre un peu cavalières de ma
part mais je pense qu'il fallait remettre un peu les idées en place pour
lecteurs peu coutumier de Windev.
> [CUT]
> Avec Windev en un an de travail, j'ai passée des journées entières pour
> recherche d'optimisations, sans pour autant trouver une solution valable
> généralement.
Des solutions coté base de données ou cote traitement ? Parce que 1 an
long ;-)
> Ne faisant non plus confiance à moi seul, j'ai travaillé
> dessus avec un spécialiste de SQL.
Un "spécialiste" de SQL t'aurait certainement conseillé de passé sur un
standard du marché (mais payant !)
> Pour l'instant je n'ai jamais lu que
> quelqu'un arrive à faire une requête Windev / HF reliant plusieurs
fichiers
> en réseau, avec plusieurs milliers de résultats triés, en moins d'une
> seconde.
Désolé mais je ne connais que 2 SGBD capable de répondre à ton besoin en
terme de "une seconde" pour des volumétrie en milliers (et millions) :
TERADATA et DB2. Dans les 2 cas on n'est plus dans la même catégorie ! Je
travaille quotidiennement aussi bien avec DB2 que du Oracle et c'est vrai
que des tris, des requêtes avec plus de 5 tables en jointure c'est
faisable...
>Le problème s'aggrave encore quand on a une base avec un minimum de
> redondances, p.ex. les lignes de commandes ne contiennent que l'ID du
> produit et ne pas celui du groupe de produits ou d'un domaine
ce
> qui nécessite des "IN" pour sélectionner. Certes, je pourrais accélérer
les
> requêtes en mettant ces rubriques dans les lignes de commandes. Mais
> ça le but de données relationnelles?
C'est l'inconvénient du SGBDR : à force de tout avoir en 3NF voire 4NF, on
se plaint des temps de réponses ! D'après toi pourquoi les SI-Décisionnels
utilisent la dénormalisation si ce n'est (en autre) par soucis de
Pour info pour certains SGBD les IN sont transformés en "...OR...OR", pour
certains SGBD il est préférable d'utiliser la commande EXIST que la
IN par contre il vaut mieux NOT IN que NOT EXIST. En gros chaque SGBD a
propre mode de fonctionnement coté interprétation de requete. Donc évitons
de comparer.
> En ce qui concerne les filtres, je préfère les requêtes d'abord parce
qu'on
> travaille sur une copie des données en local (question réseau). Mais
> parce que cela me donne plus de flexibilité pour les liaisons et rend
toutes
> les rubriques triable, sans index.
PC-Soft avait fourni une abaque pour le requetage sur les fichiers : en
fonction de la volumétrie on passe par tel ou tel mode de lecture (filtre,
vue, requete).
Emmanuel
