> Bonjour,
Soit une table contenant 427943 enregistrements.
Nous la créons de façon identique sous MySQL et HF7.
Nous lançons ensuite la requête :
select count(*) from entite
Sous MySQL, le temps d'exécution est de 0.08s
Sous HF7, nous obtenons 67.18s à la première exécution, et entre 8.20s et
8.70s pour les suivantes.
Notre requête est pourtant très simple, et devrait s'exécuter aussi
rapidement qu'un hNbEnr(ENTITE).
Pourquoi HF7 est-il si lent ? Pourquoi la 1ère requête prend-elle tant de
La taille de notre table de test est très loin des 300 milliards
d'enregistrements annoncés dans la pub de Windev. Nous pensons donc que
avons fait une erreur quelque part, mais laquelle ? Nous obtenons des
similaires si nous lançons la requête dans WdSQL ou dans notre
Notre projet doit fonctionner indifféremment sous HF7 et MySQL, et nous
souhaitons donc que le code des requêtes soit, si possible, identique.
> Bonjour,
Soit une table contenant 427943 enregistrements.
Nous la créons de façon identique sous MySQL et HF7.
Nous lançons ensuite la requête :
select count(*) from entite
Sous MySQL, le temps d'exécution est de 0.08s
Sous HF7, nous obtenons 67.18s à la première exécution, et entre 8.20s et
8.70s pour les suivantes.
Notre requête est pourtant très simple, et devrait s'exécuter aussi
rapidement qu'un hNbEnr(ENTITE).
Pourquoi HF7 est-il si lent ? Pourquoi la 1ère requête prend-elle tant de
La taille de notre table de test est très loin des 300 milliards
d'enregistrements annoncés dans la pub de Windev. Nous pensons donc que
avons fait une erreur quelque part, mais laquelle ? Nous obtenons des
similaires si nous lançons la requête dans WdSQL ou dans notre
Notre projet doit fonctionner indifféremment sous HF7 et MySQL, et nous
souhaitons donc que le code des requêtes soit, si possible, identique.
> Bonjour,
Soit une table contenant 427943 enregistrements.
Nous la créons de façon identique sous MySQL et HF7.
Nous lançons ensuite la requête :
select count(*) from entite
Sous MySQL, le temps d'exécution est de 0.08s
Sous HF7, nous obtenons 67.18s à la première exécution, et entre 8.20s et
8.70s pour les suivantes.
Notre requête est pourtant très simple, et devrait s'exécuter aussi
rapidement qu'un hNbEnr(ENTITE).
Pourquoi HF7 est-il si lent ? Pourquoi la 1ère requête prend-elle tant de
La taille de notre table de test est très loin des 300 milliards
d'enregistrements annoncés dans la pub de Windev. Nous pensons donc que
avons fait une erreur quelque part, mais laquelle ? Nous obtenons des
similaires si nous lançons la requête dans WdSQL ou dans notre
Notre projet doit fonctionner indifféremment sous HF7 et MySQL, et nous
souhaitons donc que le code des requêtes soit, si possible, identique.
> Bonjour,
>
> Soit une table contenant 427943 enregistrements.
Une pacotille quoi...
> Nous la créons de façon identique sous MySQL et HF7.
>
> Nous lançons ensuite la requête :
> select count(*) from entite
>
> Sous MySQL, le temps d'exécution est de 0.08s
en mode ligne de commande ou dans l'appli ?
> Sous HF7, nous obtenons 67.18s à la première exécution, et entre 8.20s
> 8.70s pour les suivantes.
Dans les deux cas le temps constaté est normal (à la rigueur il manquerait
la machine sur laquelle la comparaison a été faite et l'environnement
que la version MySQL).
> Notre requête est pourtant très simple, et devrait s'exécuter aussi
> rapidement qu'un hNbEnr(ENTITE).
Je pense que là vous lisez directement dans les méta données du "fichier"
contrario de la requete qui lit le fichier (normal vous lui demandais un
count(*))
> Pourquoi HF7 est-il si lent ? Pourquoi la 1ère requête prend-elle tant
temps ?
HF7 comme la majorité des SGBD se base maintenant sur ses statistiques. On
les mets à jour avec les HOptimiseRequete(). Sinon si il n'y a aucun
tout le fichier est parcouru. Quels sont les temps si vous mettez un index
(une table sans index c'est une table sans PK donc une table de
?
Le premier temps plus lent c'est normal c'est la phase de préparation de
requete...
> La taille de notre table de test est très loin des 300 milliards
> d'enregistrements annoncés dans la pub de Windev. Nous pensons donc que
nous
> avons fait une erreur quelque part, mais laquelle ? Nous obtenons des
temps
> similaires si nous lançons la requête dans WdSQL ou dans notre
application.
>
> Notre projet doit fonctionner indifféremment sous HF7 et MySQL, et nous
> souhaitons donc que le code des requêtes soit, si possible, identique.
> (anonymat pour éviter des accusations de dénigrement)
No comment
> Bonjour,
>
> Soit une table contenant 427943 enregistrements.
Une pacotille quoi...
> Nous la créons de façon identique sous MySQL et HF7.
>
> Nous lançons ensuite la requête :
> select count(*) from entite
>
> Sous MySQL, le temps d'exécution est de 0.08s
en mode ligne de commande ou dans l'appli ?
> Sous HF7, nous obtenons 67.18s à la première exécution, et entre 8.20s
> 8.70s pour les suivantes.
Dans les deux cas le temps constaté est normal (à la rigueur il manquerait
la machine sur laquelle la comparaison a été faite et l'environnement
que la version MySQL).
> Notre requête est pourtant très simple, et devrait s'exécuter aussi
> rapidement qu'un hNbEnr(ENTITE).
Je pense que là vous lisez directement dans les méta données du "fichier"
contrario de la requete qui lit le fichier (normal vous lui demandais un
count(*))
> Pourquoi HF7 est-il si lent ? Pourquoi la 1ère requête prend-elle tant
temps ?
HF7 comme la majorité des SGBD se base maintenant sur ses statistiques. On
les mets à jour avec les HOptimiseRequete(). Sinon si il n'y a aucun
tout le fichier est parcouru. Quels sont les temps si vous mettez un index
(une table sans index c'est une table sans PK donc une table de
?
Le premier temps plus lent c'est normal c'est la phase de préparation de
requete...
> La taille de notre table de test est très loin des 300 milliards
> d'enregistrements annoncés dans la pub de Windev. Nous pensons donc que
nous
> avons fait une erreur quelque part, mais laquelle ? Nous obtenons des
temps
> similaires si nous lançons la requête dans WdSQL ou dans notre
application.
>
> Notre projet doit fonctionner indifféremment sous HF7 et MySQL, et nous
> souhaitons donc que le code des requêtes soit, si possible, identique.
> (anonymat pour éviter des accusations de dénigrement)
No comment
> Bonjour,
>
> Soit une table contenant 427943 enregistrements.
Une pacotille quoi...
> Nous la créons de façon identique sous MySQL et HF7.
>
> Nous lançons ensuite la requête :
> select count(*) from entite
>
> Sous MySQL, le temps d'exécution est de 0.08s
en mode ligne de commande ou dans l'appli ?
> Sous HF7, nous obtenons 67.18s à la première exécution, et entre 8.20s
> 8.70s pour les suivantes.
Dans les deux cas le temps constaté est normal (à la rigueur il manquerait
la machine sur laquelle la comparaison a été faite et l'environnement
que la version MySQL).
> Notre requête est pourtant très simple, et devrait s'exécuter aussi
> rapidement qu'un hNbEnr(ENTITE).
Je pense que là vous lisez directement dans les méta données du "fichier"
contrario de la requete qui lit le fichier (normal vous lui demandais un
count(*))
> Pourquoi HF7 est-il si lent ? Pourquoi la 1ère requête prend-elle tant
temps ?
HF7 comme la majorité des SGBD se base maintenant sur ses statistiques. On
les mets à jour avec les HOptimiseRequete(). Sinon si il n'y a aucun
tout le fichier est parcouru. Quels sont les temps si vous mettez un index
(une table sans index c'est une table sans PK donc une table de
?
Le premier temps plus lent c'est normal c'est la phase de préparation de
requete...
> La taille de notre table de test est très loin des 300 milliards
> d'enregistrements annoncés dans la pub de Windev. Nous pensons donc que
nous
> avons fait une erreur quelque part, mais laquelle ? Nous obtenons des
temps
> similaires si nous lançons la requête dans WdSQL ou dans notre
application.
>
> Notre projet doit fonctionner indifféremment sous HF7 et MySQL, et nous
> souhaitons donc que le code des requêtes soit, si possible, identique.
> (anonymat pour éviter des accusations de dénigrement)
No comment
Est-ce que quelqu'un a une explication?
Est-ce normal ?
Est-ce que quelqu'un a une explication?
Est-ce normal ?
Est-ce que quelqu'un a une explication?
Est-ce normal ?
> La raison de la lenteur de la première lecture est assez simple et a été
mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
produits ne lisent que les lignes affichées. Les lectures suivantes sont
trouvé dans le cache et donc plus rapides.
> La raison de la lenteur de la première lecture est assez simple et a été
mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
produits ne lisent que les lignes affichées. Les lectures suivantes sont
trouvé dans le cache et donc plus rapides.
> La raison de la lenteur de la première lecture est assez simple et a été
mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
produits ne lisent que les lignes affichées. Les lectures suivantes sont
trouvé dans le cache et donc plus rapides.
La raison de la lenteur de la première lecture est assez simple et a été
mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
produits ne lisent que les lignes affichées. Les lectures suivantes sont
trouvé dans le cache et donc plus rapides.
Une requête de type "select count(*) from table" renvoie 1 valeur et non un
paquet de lignes !
67 secondes pour renvoyer le nombre total de lignes d'une table, sans aucune
clause WHERE est inacceptable (en effet dans ce cas il est inutile de
parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4 3.2Ghz),
alors que le 0.08s en MySql est obtenu en accédant à une autre machine du
RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
échantillon des données que nous devons traiter dans la verison finale (qui
va contenir environ 2000000 d'enregistrements). Nous espérons que les temps
ne seront pas proportionnels :-(
Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes (mais
pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements comme
sur un autre de nos projets en Oracle) ? En passant, voilà de quoi faire
réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count de +10
milliards en 0.14s) :
------------------------------------------------------------------
select count(*) from mesures
Result 1 field(s), 1 record(s), time 0.14 sec
count(*)
---------------------
10.006.507.317
------------------------------------------------------------------
En recherchant une solution sur les archives je vois que certains
WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une explication à
nos problèmes de perf ?
Merci
...
La raison de la lenteur de la première lecture est assez simple et a été
mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
produits ne lisent que les lignes affichées. Les lectures suivantes sont
trouvé dans le cache et donc plus rapides.
Une requête de type "select count(*) from table" renvoie 1 valeur et non un
paquet de lignes !
67 secondes pour renvoyer le nombre total de lignes d'une table, sans aucune
clause WHERE est inacceptable (en effet dans ce cas il est inutile de
parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4 3.2Ghz),
alors que le 0.08s en MySql est obtenu en accédant à une autre machine du
RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
échantillon des données que nous devons traiter dans la verison finale (qui
va contenir environ 2000000 d'enregistrements). Nous espérons que les temps
ne seront pas proportionnels :-(
Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes (mais
pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements comme
sur un autre de nos projets en Oracle) ? En passant, voilà de quoi faire
réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count de +10
milliards en 0.14s) :
------------------------------------------------------------------
select count(*) from mesures
Result 1 field(s), 1 record(s), time 0.14 sec
count(*)
---------------------
10.006.507.317
------------------------------------------------------------------
En recherchant une solution sur les archives je vois que certains
WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une explication à
nos problèmes de perf ?
Merci
...
La raison de la lenteur de la première lecture est assez simple et a été
mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
produits ne lisent que les lignes affichées. Les lectures suivantes sont
trouvé dans le cache et donc plus rapides.
Une requête de type "select count(*) from table" renvoie 1 valeur et non un
paquet de lignes !
67 secondes pour renvoyer le nombre total de lignes d'une table, sans aucune
clause WHERE est inacceptable (en effet dans ce cas il est inutile de
parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4 3.2Ghz),
alors que le 0.08s en MySql est obtenu en accédant à une autre machine du
RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
échantillon des données que nous devons traiter dans la verison finale (qui
va contenir environ 2000000 d'enregistrements). Nous espérons que les temps
ne seront pas proportionnels :-(
Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes (mais
pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements comme
sur un autre de nos projets en Oracle) ? En passant, voilà de quoi faire
réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count de +10
milliards en 0.14s) :
------------------------------------------------------------------
select count(*) from mesures
Result 1 field(s), 1 record(s), time 0.14 sec
count(*)
---------------------
10.006.507.317
------------------------------------------------------------------
En recherchant une solution sur les archives je vois que certains
WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une explication à
nos problèmes de perf ?
Merci
...
Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre appli
pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD standard
comme Oracle, sqlserver, mysql, PostgreSQL car ce peut être un élément
de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de la
confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations monopostes
et pour des petites quantités. Il est peut être alors plus facile
d'installer des fichiers HF et les pb de perfs sont inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème pas
se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :
>> La raison de la lenteur de la première lecture est assez simple et a
>> mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
>> fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
>> produits ne lisent que les lignes affichées. Les lectures suivantes
>> trouvé dans le cache et donc plus rapides.
>
> Une requête de type "select count(*) from table" renvoie 1 valeur et non
> paquet de lignes !
>
> 67 secondes pour renvoyer le nombre total de lignes d'une table, sans
> clause WHERE est inacceptable (en effet dans ce cas il est inutile de
> parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4
> alors que le 0.08s en MySql est obtenu en accédant à une autre machine
> RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
>
> Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
> échantillon des données que nous devons traiter dans la verison finale
> va contenir environ 2000000 d'enregistrements). Nous espérons que les
> ne seront pas proportionnels :-(
>
> Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes
> pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements
> sur un autre de nos projets en Oracle) ? En passant, voilà de quoi faire
> réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count de
> milliards en 0.14s) :
>
> ------------------------------------------------------------------
> select count(*) from mesures
>
> Result 1 field(s), 1 record(s), time 0.14 sec
>
> count(*)
> ---------------------
> 10.006.507.317
>
> ------------------------------------------------------------------
>
> En recherchant une solution sur les archives je vois que certains
> WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
> hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une explication
> nos problèmes de perf ?
>
> Merci
>
> ...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre appli
pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD standard
comme Oracle, sqlserver, mysql, PostgreSQL car ce peut être un élément
de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de la
confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations monopostes
et pour des petites quantités. Il est peut être alors plus facile
d'installer des fichiers HF et les pb de perfs sont inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème pas
se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :
>> La raison de la lenteur de la première lecture est assez simple et a
>> mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
>> fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
>> produits ne lisent que les lignes affichées. Les lectures suivantes
>> trouvé dans le cache et donc plus rapides.
>
> Une requête de type "select count(*) from table" renvoie 1 valeur et non
> paquet de lignes !
>
> 67 secondes pour renvoyer le nombre total de lignes d'une table, sans
> clause WHERE est inacceptable (en effet dans ce cas il est inutile de
> parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4
> alors que le 0.08s en MySql est obtenu en accédant à une autre machine
> RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
>
> Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
> échantillon des données que nous devons traiter dans la verison finale
> va contenir environ 2000000 d'enregistrements). Nous espérons que les
> ne seront pas proportionnels :-(
>
> Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes
> pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements
> sur un autre de nos projets en Oracle) ? En passant, voilà de quoi faire
> réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count de
> milliards en 0.14s) :
>
> ------------------------------------------------------------------
> select count(*) from mesures
>
> Result 1 field(s), 1 record(s), time 0.14 sec
>
> count(*)
> ---------------------
> 10.006.507.317
>
> ------------------------------------------------------------------
>
> En recherchant une solution sur les archives je vois que certains
> WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
> hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une explication
> nos problèmes de perf ?
>
> Merci
>
> ...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre appli
pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD standard
comme Oracle, sqlserver, mysql, PostgreSQL car ce peut être un élément
de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de la
confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations monopostes
et pour des petites quantités. Il est peut être alors plus facile
d'installer des fichiers HF et les pb de perfs sont inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème pas
se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :
>> La raison de la lenteur de la première lecture est assez simple et a
>> mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
>> fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
>> produits ne lisent que les lignes affichées. Les lectures suivantes
>> trouvé dans le cache et donc plus rapides.
>
> Une requête de type "select count(*) from table" renvoie 1 valeur et non
> paquet de lignes !
>
> 67 secondes pour renvoyer le nombre total de lignes d'une table, sans
> clause WHERE est inacceptable (en effet dans ce cas il est inutile de
> parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4
> alors que le 0.08s en MySql est obtenu en accédant à une autre machine
> RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
>
> Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
> échantillon des données que nous devons traiter dans la verison finale
> va contenir environ 2000000 d'enregistrements). Nous espérons que les
> ne seront pas proportionnels :-(
>
> Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes
> pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements
> sur un autre de nos projets en Oracle) ? En passant, voilà de quoi faire
> réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count de
> milliards en 0.14s) :
>
> ------------------------------------------------------------------
> select count(*) from mesures
>
> Result 1 field(s), 1 record(s), time 0.14 sec
>
> count(*)
> ---------------------
> 10.006.507.317
>
> ------------------------------------------------------------------
>
> En recherchant une solution sur les archives je vois que certains
> WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
> hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une explication
> nos problèmes de perf ?
>
> Merci
>
> ...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Bonjour,
Nous nous étions posé cette question il y a quelque temps pour une gestion
de planning et en fait la réponse avait été HF7 pour une histoire de coût.
HF7 est gratuit et, effectivement, plus facile à installer qu'une base SQL.
Du moment où l'on veut cibler une vente à un large public et en boîte dans
les grandes surfaces spécialisées, nous n'avions pas trouvé de base Sql
gratuite, pour une utilisation commerciale, et facile à installer en réseau
par l'utilisateur final.
Notre manque de connaissance y avait peut-être été pour quelque chose, mais
nos questions à ce moment là sur le sujet n'avaient pas eu réellement de
réponse. Pour les clients que nous avions, avant que nous mettions à notre
compte, étaient pour certains produits en HF et d'autres produits plus
conséquents en SQL Serveur. Mais ces clients étaient maintenus par nos
techniciens qui allaient sur site.
Si nous nous sommes trompés, je souhaiterais que quelqu'un nous indique quoi
utiliser et comment l'installer, cela ouvrirait sûrement notre esprit
étriqué.
Bonjour,
Nous nous étions posé cette question il y a quelque temps pour une gestion
de planning et en fait la réponse avait été HF7 pour une histoire de coût.
HF7 est gratuit et, effectivement, plus facile à installer qu'une base SQL.
Du moment où l'on veut cibler une vente à un large public et en boîte dans
les grandes surfaces spécialisées, nous n'avions pas trouvé de base Sql
gratuite, pour une utilisation commerciale, et facile à installer en réseau
par l'utilisateur final.
Notre manque de connaissance y avait peut-être été pour quelque chose, mais
nos questions à ce moment là sur le sujet n'avaient pas eu réellement de
réponse. Pour les clients que nous avions, avant que nous mettions à notre
compte, étaient pour certains produits en HF et d'autres produits plus
conséquents en SQL Serveur. Mais ces clients étaient maintenus par nos
techniciens qui allaient sur site.
Si nous nous sommes trompés, je souhaiterais que quelqu'un nous indique quoi
utiliser et comment l'installer, cela ouvrirait sûrement notre esprit
étriqué.
Bonjour,
Nous nous étions posé cette question il y a quelque temps pour une gestion
de planning et en fait la réponse avait été HF7 pour une histoire de coût.
HF7 est gratuit et, effectivement, plus facile à installer qu'une base SQL.
Du moment où l'on veut cibler une vente à un large public et en boîte dans
les grandes surfaces spécialisées, nous n'avions pas trouvé de base Sql
gratuite, pour une utilisation commerciale, et facile à installer en réseau
par l'utilisateur final.
Notre manque de connaissance y avait peut-être été pour quelque chose, mais
nos questions à ce moment là sur le sujet n'avaient pas eu réellement de
réponse. Pour les clients que nous avions, avant que nous mettions à notre
compte, étaient pour certains produits en HF et d'autres produits plus
conséquents en SQL Serveur. Mais ces clients étaient maintenus par nos
techniciens qui allaient sur site.
Si nous nous sommes trompés, je souhaiterais que quelqu'un nous indique quoi
utiliser et comment l'installer, cela ouvrirait sûrement notre esprit
étriqué.
Bonjour,
Nous nous étions posé cette question il y a quelque temps pour une
de planning et en fait la réponse avait été HF7 pour une histoire de
HF7 est gratuit et, effectivement, plus facile à installer qu'une
Du moment où l'on veut cibler une vente à un large public et en boîte
les grandes surfaces spécialisées, nous n'avions pas trouvé de base Sql
gratuite, pour une utilisation commerciale, et facile à installer en
par l'utilisateur final.
Notre manque de connaissance y avait peut-être été pour quelque
nos questions à ce moment là sur le sujet n'avaient pas eu réellement de
réponse. Pour les clients que nous avions, avant que nous mettions à
compte, étaient pour certains produits en HF et d'autres produits plus
conséquents en SQL Serveur. Mais ces clients étaient maintenus par nos
techniciens qui allaient sur site.
Si nous nous sommes trompés, je souhaiterais que quelqu'un nous
utiliser et comment l'installer, cela ouvrirait sûrement notre esprit
étriqué.
Bonjour,
Nous nous étions posé cette question il y a quelque temps pour une
de planning et en fait la réponse avait été HF7 pour une histoire de
HF7 est gratuit et, effectivement, plus facile à installer qu'une
Du moment où l'on veut cibler une vente à un large public et en boîte
les grandes surfaces spécialisées, nous n'avions pas trouvé de base Sql
gratuite, pour une utilisation commerciale, et facile à installer en
par l'utilisateur final.
Notre manque de connaissance y avait peut-être été pour quelque
nos questions à ce moment là sur le sujet n'avaient pas eu réellement de
réponse. Pour les clients que nous avions, avant que nous mettions à
compte, étaient pour certains produits en HF et d'autres produits plus
conséquents en SQL Serveur. Mais ces clients étaient maintenus par nos
techniciens qui allaient sur site.
Si nous nous sommes trompés, je souhaiterais que quelqu'un nous
utiliser et comment l'installer, cela ouvrirait sûrement notre esprit
étriqué.
Bonjour,
Nous nous étions posé cette question il y a quelque temps pour une
de planning et en fait la réponse avait été HF7 pour une histoire de
HF7 est gratuit et, effectivement, plus facile à installer qu'une
Du moment où l'on veut cibler une vente à un large public et en boîte
les grandes surfaces spécialisées, nous n'avions pas trouvé de base Sql
gratuite, pour une utilisation commerciale, et facile à installer en
par l'utilisateur final.
Notre manque de connaissance y avait peut-être été pour quelque
nos questions à ce moment là sur le sujet n'avaient pas eu réellement de
réponse. Pour les clients que nous avions, avant que nous mettions à
compte, étaient pour certains produits en HF et d'autres produits plus
conséquents en SQL Serveur. Mais ces clients étaient maintenus par nos
techniciens qui allaient sur site.
Si nous nous sommes trompés, je souhaiterais que quelqu'un nous
utiliser et comment l'installer, cela ouvrirait sûrement notre esprit
étriqué.
Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre appli
pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD standard
comme Oracle, sqlserver, mysql, PostgreSQL car ce peut être un élément
de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de la
confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations monopostes
et pour des petites quantités. Il est peut être alors plus facile
d'installer des fichiers HF et les pb de perfs sont inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème pas
se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :
>> La raison de la lenteur de la première lecture est assez simple et a
>> mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
>> fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
>> produits ne lisent que les lignes affichées. Les lectures suivantes
>> trouvé dans le cache et donc plus rapides.
>
> Une requête de type "select count(*) from table" renvoie 1 valeur et non
> paquet de lignes !
>
> 67 secondes pour renvoyer le nombre total de lignes d'une table, sans
> clause WHERE est inacceptable (en effet dans ce cas il est inutile de
> parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4
> alors que le 0.08s en MySql est obtenu en accédant à une autre machine
> RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
>
> Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
> échantillon des données que nous devons traiter dans la verison finale
> va contenir environ 2000000 d'enregistrements). Nous espérons que les
> ne seront pas proportionnels :-(
>
> Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes
> pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements
> sur un autre de nos projets en Oracle) ? En passant, voilà de quoi faire
> réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count de
> milliards en 0.14s) :
>
> ------------------------------------------------------------------
> select count(*) from mesures
>
> Result 1 field(s), 1 record(s), time 0.14 sec
>
> count(*)
> ---------------------
> 10.006.507.317
>
> ------------------------------------------------------------------
>
> En recherchant une solution sur les archives je vois que certains
> WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
> hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une explication
> nos problèmes de perf ?
>
> Merci
>
> ...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre appli
pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD standard
comme Oracle, sqlserver, mysql, PostgreSQL car ce peut être un élément
de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de la
confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations monopostes
et pour des petites quantités. Il est peut être alors plus facile
d'installer des fichiers HF et les pb de perfs sont inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème pas
se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :
>> La raison de la lenteur de la première lecture est assez simple et a
>> mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
>> fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
>> produits ne lisent que les lignes affichées. Les lectures suivantes
>> trouvé dans le cache et donc plus rapides.
>
> Une requête de type "select count(*) from table" renvoie 1 valeur et non
> paquet de lignes !
>
> 67 secondes pour renvoyer le nombre total de lignes d'une table, sans
> clause WHERE est inacceptable (en effet dans ce cas il est inutile de
> parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4
> alors que le 0.08s en MySql est obtenu en accédant à une autre machine
> RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
>
> Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
> échantillon des données que nous devons traiter dans la verison finale
> va contenir environ 2000000 d'enregistrements). Nous espérons que les
> ne seront pas proportionnels :-(
>
> Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes
> pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements
> sur un autre de nos projets en Oracle) ? En passant, voilà de quoi faire
> réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count de
> milliards en 0.14s) :
>
> ------------------------------------------------------------------
> select count(*) from mesures
>
> Result 1 field(s), 1 record(s), time 0.14 sec
>
> count(*)
> ---------------------
> 10.006.507.317
>
> ------------------------------------------------------------------
>
> En recherchant une solution sur les archives je vois que certains
> WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
> hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une explication
> nos problèmes de perf ?
>
> Merci
>
> ...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Moi ce que je ne comprends pas, c'est le pourquoi de sortir votre appli
pour mySQL et HF7 ???
Je veux bien comprendre le besoin de s'ouvrir à plusieurs SGBD standard
comme Oracle, sqlserver, mysql, PostgreSQL car ce peut être un élément
de décision pour le client.
Mais HF ? Je doute que cela soit un argument commercial du fait de la
confidentialité de cette base.
Donc pourquoi ne pas proposer que mysql ?
Ou alors, on choisit HF car on doit avoir des installations monopostes
et pour des petites quantités. Il est peut être alors plus facile
d'installer des fichiers HF et les pb de perfs sont inexistants.
Mais quand on parle de 2000000 d'enreg, la question ne devrait mème pas
se poser, surtout si notre code est dès le depart orienté SQL.
... a exposé le 10/06/2004 :
>> La raison de la lenteur de la première lecture est assez simple et a
>> mentionné à plusieures reprises sur ce forum: Windev ecrit dans un
>> fichier et lit en mémoire chaque ligne du résultat, tandis que d'autres
>> produits ne lisent que les lignes affichées. Les lectures suivantes
>> trouvé dans le cache et donc plus rapides.
>
> Une requête de type "select count(*) from table" renvoie 1 valeur et non
> paquet de lignes !
>
> 67 secondes pour renvoyer le nombre total de lignes d'une table, sans
> clause WHERE est inacceptable (en effet dans ce cas il est inutile de
> parcourir les index). En plus ce résultat est obtenu EN LOCAL (P4
> alors que le 0.08s en MySql est obtenu en accédant à une autre machine
> RÉSEAU (P3 500Mhz) qui roule MySQL sous Linux.
>
> Ce qui nous fait peur, c'est que les 427000 enregistrements sont un
> échantillon des données que nous devons traiter dans la verison finale
> va contenir environ 2000000 d'enregistrements). Nous espérons que les
> ne seront pas proportionnels :-(
>
> Sommes-nous les seuls à utiliser SQL/HF7 avec des tables conséquentes
> pas énormes, nous n'en sommes pas à +10 milliards d'enregistrements
> sur un autre de nos projets en Oracle) ? En passant, voilà de quoi faire
> réflechir pcsoft sur les performances de HF7 (Oracle renvoie un count de
> milliards en 0.14s) :
>
> ------------------------------------------------------------------
> select count(*) from mesures
>
> Result 1 field(s), 1 record(s), time 0.14 sec
>
> count(*)
> ---------------------
> 10.006.507.317
>
> ------------------------------------------------------------------
>
> En recherchant une solution sur les archives je vois que certains
> WDprogrammeurs affirment que le SQL/HF7 est plus lent que les ordres
> hyperfile classiques (hLit*). Est-ce réel ? Ce serait-il une explication
> nos problèmes de perf ?
>
> Merci
>
> ...
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
> [CUT]
> Le peu de réponses reçues à nos questions signifierait que ces
performances
> sont normales ? Pourquoi est on si lent alors qu'on est très loin des
> volumes maximums annoncés par PcSoft dans ses publicités (mensongères?),
> soit +300 milliards de records ?
Sans être mesquin je vous trouve un petit peu naif avec ce nombre
d'enregistrements. Rien qu'en exploitation de disques cela semble
Il y aussi une différence entre ce qu'il est théoriquement possible de
et techniquement réalisable.
--
Emmanuel
> [CUT]
> Le peu de réponses reçues à nos questions signifierait que ces
performances
> sont normales ? Pourquoi est on si lent alors qu'on est très loin des
> volumes maximums annoncés par PcSoft dans ses publicités (mensongères?),
> soit +300 milliards de records ?
Sans être mesquin je vous trouve un petit peu naif avec ce nombre
d'enregistrements. Rien qu'en exploitation de disques cela semble
Il y aussi une différence entre ce qu'il est théoriquement possible de
et techniquement réalisable.
--
Emmanuel
> [CUT]
> Le peu de réponses reçues à nos questions signifierait que ces
performances
> sont normales ? Pourquoi est on si lent alors qu'on est très loin des
> volumes maximums annoncés par PcSoft dans ses publicités (mensongères?),
> soit +300 milliards de records ?
Sans être mesquin je vous trouve un petit peu naif avec ce nombre
d'enregistrements. Rien qu'en exploitation de disques cela semble
Il y aussi une différence entre ce qu'il est théoriquement possible de
et techniquement réalisable.
--
Emmanuel
