WD 10 / 11 - Fiabilité de HF CS ou HF

Salut,

Je suis en HF C/S. 200Mo de base, 30 utilisateurs. Aucun pb. J'avais fait
des test au début en MySQL. Pas plus de rapidité...

Moi je suis staisfait, même avec un VPN à 512k, ca marche bien mais j'ai du
pas mal optimisé le code. J'ai environ 3 bases de données avec environ 100
tables au totales. Les plus grosses ont 1 200 000 enregistrements.

Voila
Francis.


"JPC" <justinien@fiskobel.com> a écrit dans le message de news:
45463a0d$0$1136$ba620e4c@news.skynet.be...

Bonjour,

Après avoir lu les nombreux messages sur la fiabilité des bases de
données, j'avoue
que je commence à sérieusement me poser des question sur l'application que
nous développons en ce moment. Celle ci est basée sur HF / CS...

J'aimerais vraiment savoir si il y a une méthode de programmation à
respecter pour éviter des problèmes avec HF. Ce qui m'a fait un peu peur
c'est l'histoire des requêtes Insert qui selon certains d'entre vous ne
sont pas bien gérées par HF.

Qu'en est il exactement. Peux t on se passer de ces requêtes et utiliser
plutôt des commandes H ? Et si oui, qu'en est il de la rapidité de
l'application ...

Vous parlez bcp de MySql ... Est ce bcp plus rapide que HF. Peux-t-on
passer facilement en cours de route de HF vers MySql ? Est ce utile pour
une application qui ne devrait en principe pas tourner sur plus de 20
postes à la fois ...

A partir de quand d'après vous, faut il opter pour autre chose que HF CS ?

Merci d'avance de nous éclairer ...

JPC

"JPC" <justinien@fiskobel.com> a écrit dans le message de
news:45463a0d$0$1136$ba620e4c@news.skynet.be...

J'aimerais vraiment savoir si il y a une méthode de programmation à
respecter pour éviter des problèmes avec HF. Ce qui m'a fait un peu peur
c'est l'histoire des requêtes Insert qui selon certains d'entre vous ne

sont

pas bien gérées par HF.

bonjour

utilisent principalement HF, j'ai essayé CS en V10 mais ca me mettait le
serveur à 100% sans comprendre pourquoi juste avec une petite appli donc
j'ai laissé tombé.
je n'utilise que tres rarement les requetes sql car cela implique 2 choses :
- de designer les indexs en fonction de ce que l'on veut faire
cela n'est pas mal en soit, mais a la longue on se retrouve avec une
tripotée d'index sans savoir lesquels sont rééllement util
(alors qu'avec des fonctions HLitRecherche, les index sont
explicitement nommés)
- d'avoir les stats à jours dans les fichiers
et sur les gros fichiers, recalculer les stats, même une fois par
semaine ca finit par être très très lourd.

sinon pour hf
- aucun pb rencontré comme ceux énoncés y'a pas longtemps (doublon sur clé
primaire)
- par contre j'ai eu assez régulièrement jusqu'à la v9 des indexs qui se
vérolaient sans savoir pourquoi (nécessité d'avoir un Hreindex dans son code
pour dépanner le client)
- depuis la v10, ca reste tres épisodique.

Gilles a formulé ce lundi :

JPC a formulé ce lundi :

Bonjour,

Après avoir lu les nombreux messages sur la fiabilité des bases de données,
j'avoue
que je commence à sérieusement me poser des question sur l'application que
nous développons en ce moment. Celle ci est basée sur HF / CS...

[...]

En ce qui me concerne : les delete de masse, les updates de masse, sélection
complexes, avec des clauses where nécessaires, j'utilis des requêtes.

Ajout, modification, Suppression d'un enregistrement simple, ordres H.

Une très bonne méthode (j'ai la même :)

[...]

Vous parlez bcp de MySql ... Est ce bcp plus rapide que HF. Peux-t-on
passer facilement en cours de route de HF vers MySql ? Est ce utile pour
une application qui ne devrait en principe pas tourner sur plus de 20
postes à la fois ...

Je n'ai pas fait de benchs.
Mais je n'ai pas le moindre doute sur le fait que MySQL soit largement plus
rapide que HF/CS.

Nous commencons nos nouveau projet avec MySQL :
Notre sentiment :
- En lecture => MySQL est beaucoup plus rapide
- En modification => je sais pas
- En ajout (insert) => MySQL semble beaucoup plus lent (en fait, nous
somme très decu sur ce point).

Vbig a écrit :

Nous commencons nos nouveau projet avec MySQL :
Notre sentiment :
- En lecture => MySQL est beaucoup plus rapide
- En modification => je sais pas
- En ajout (insert) => MySQL semble beaucoup plus lent (en fait, nous
somme très decu sur ce point).

en insert de masse ? ou avec les commandes H... ?
en masse, il vaut mieux envelopper avec une transaction.


--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com

Gilles a écrit :

Dans son message précédent, Vbig a écrit :

Gilles a formulé ce lundi :

JPC a formulé ce lundi :

Bonjour,

Après avoir lu les nombreux messages sur la fiabilité des bases de
données, j'avoue
que je commence à sérieusement me poser des question sur l'application
que nous développons en ce moment. Celle ci est basée sur HF / CS...

[...]

En ce qui me concerne : les delete de masse, les updates de masse,
sélection complexes, avec des clauses where nécessaires, j'utilis des
requêtes.

Ajout, modification, Suppression d'un enregistrement simple, ordres H.

Une très bonne méthode (j'ai la même :)

Je vais bientôt travailler sur une problématique HF/CS avec des très
grosses bases de données à intégrer. Pour l'instant ces imports durent
6 heures, à moi de faire mieux.
Mais je pense que le Hajoute n'est pas forcément le plus adapté mème si
à programmer, je trouve ça très propre.
Pour en revenir à mysql, le bulk insert est vraiment bluffant.

Savez vous si cela serait autorisé en HF/CS ? (syntaxe approximative)

INSERT INTO MATABLE (ZON1,ZON2,ZON23) VALUES
(123,'toto',45),
(1234,'tata',415),
(5123,'titi',145),
(1523,'tutu',451)

[...]

Vous parlez bcp de MySql ... Est ce bcp plus rapide que HF. Peux-t-on
passer facilement en cours de route de HF vers MySql ? Est ce utile pour
une application qui ne devrait en principe pas tourner sur plus de 20
postes à la fois ...

en requête pure, je pense que mysql serait plus rapide.

Je n'ai pas fait de benchs.
Mais je n'ai pas le moindre doute sur le fait que MySQL soit largement
plus rapide que HF/CS.

Nous commencons nos nouveau projet avec MySQL :
Notre sentiment :
- En lecture => MySQL est beaucoup plus rapide
- En modification => je sais pas
- En ajout (insert) => MySQL semble beaucoup plus lent (en fait, nous somme
très decu sur ce point).

Ce dernier point est intriguant...
Pas de triggers?

en mysql 5
mais ensuite vieux débat; moi je n'utilise pas les triggers car je veux
passer d'une base à l'autre, donc je fuis au maximum le code
propriétaire.
Voilà pourquoi je ne veux pas utiliser le Hajoute pour une base sql.

Je n'ai jamais rien remarqué en ajout, les traitements me paraissent tous
instantanés.

--
Eric Roumégou
Webmaster des Wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci dessus pour me contacter en privé)

Roumegou Eric a écrit :

Gilles a écrit :
> Dans son message précédent, Vbig a écrit :
>> Gilles a formulé ce lundi :
>>> JPC a formulé ce lundi :
>>>> Bonjour,
>>>>
>>>> Après avoir lu les nombreux messages sur la fiabilité des bases de
>>>> données, j'avoue
>>>> que je commence à sérieusement me poser des question sur l'appli cation
>>>> que nous développons en ce moment. Celle ci est basée sur HF / C S...
>> [...]
>>>
>>> En ce qui me concerne : les delete de masse, les updates de masse,
>>> sélection complexes, avec des clauses where nécessaires, j'utilis des
>>> requêtes.
>>>
>>> Ajout, modification, Suppression d'un enregistrement simple, ordres H.
>> Une très bonne méthode (j'ai la même :)

Je vais bientôt travailler sur une problématique HF/CS avec des très
grosses bases de données à intégrer. Pour l'instant ces imports dur ent
6 heures, à moi de faire mieux.
Mais je pense que le Hajoute n'est pas forcément le plus adapté mèm e si
à programmer, je trouve ça très propre.
Pour en revenir à mysql, le bulk insert est vraiment bluffant.

Savez vous si cela serait autorisé en HF/CS ? (syntaxe approximative)

INSERT INTO MATABLE (ZON1,ZON2,ZON23) VALUES
(123,'toto',45),
(1234,'tata',415),
(5123,'titi',145),
(1523,'tutu',451)

Romu m'avait filer la solution à l'époque : HimporteTexte. C'est
très rapide. Tu génères un fichier texte, tu importes que demander
de plus. C'est cette technique que j'ai utilisé avec certains accès
natif SQMX pour gérer les ordres précédent dans des fichiers HF
locaux.

>>
>> [...]
>>>
>>>> Vous parlez bcp de MySql ... Est ce bcp plus rapide que HF. Peux-t-on
>>>> passer facilement en cours de route de HF vers MySql ? Est ce utile pour
>>>> une application qui ne devrait en principe pas tourner sur plus de 20
>>>> postes à la fois ...

en requête pure, je pense que mysql serait plus rapide.

>>>
>>> Je n'ai pas fait de benchs.
>>> Mais je n'ai pas le moindre doute sur le fait que MySQL soit largement
>>> plus rapide que HF/CS.
>>
>> Nous commencons nos nouveau projet avec MySQL :
>> Notre sentiment :
>> - En lecture => MySQL est beaucoup plus rapide
>> - En modification => je sais pas
>> - En ajout (insert) => MySQL semble beaucoup plus lent (en fait, nou s somme
>> très decu sur ce point).
>
> Ce dernier point est intriguant...
> Pas de triggers?
en mysql 5
mais ensuite vieux débat; moi je n'utilise pas les triggers car je veux
passer d'une base à l'autre, donc je fuis au maximum le code
propriétaire.
Voilà pourquoi je ne veux pas utiliser le Hajoute pour une base sql.

>
> Je n'ai jamais rien remarqué en ajout, les traitements me paraissent tous
> instantanés.

--
Eric Roumégou
Webmaster des Wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci dessus pour me contacter en privé)

jacques trepp a formulé ce mardi :

Vbig a écrit :

Nous commencons nos nouveau projet avec MySQL :
Notre sentiment :
- En lecture => MySQL est beaucoup plus rapide
- En modification => je sais pas
- En ajout (insert) => MySQL semble beaucoup plus lent (en fait, nous somme
très decu sur ce point).

en insert de masse ? ou avec les commandes H... ?
en masse, il vaut mieux envelopper avec une transaction.

Nous n'utilisons aucun ordre HF sur mysql
MySQL avec requete INSERT

L'insert de masse de type
*
INSERT INTO MATABLE (ZON1,ZON2,ZON23) VALUES
(123,'toto',45),
(1234,'tata',415),
(5123,'titi',145),
(1523,'tutu',451)
*
ne peut pas être utilisé facilement dans le cas précis :


Le traitement importants des données d'un fichier texte ou chaque ligne
de celui ci correspond à des données stockées dans plusieurs table,
Certainnes de ces données sont redondante dans le fichier et n'ont pas
leur place dans la nouvelle base, L'import doit créer correctement les
référence commune dans des tables dictionnaires, et n'inscrire que
l'identifiant généré pour les lignes suivante faisant référence au même
données dictionnaires dans le fichier 'central'.

Bref, des traitement d'import que l'ont fait régulièrement dans des
base HF, ces memes traitements traduit en requete sql pour mysql
s'effondre.

Une fois passé le cap de l'import, MySQL est plus rapide dans les
traitements de lecture/consolidation.


Petit exemple de fichier texte
Nomclient,nomreprésentant,nomsecteur
toto,riri,susu
tata,riri,susu
titi,roro,susu

Traduit
Table client table represetant table secteur
toto,1,1 1,riri 1,susu
tata,1,1 2,roro
titi,2,1

Exmple simpliste mais qui reflete assez bien la problématique :)

Vbig a écrit :

jacques trepp a formulé ce mardi :

Vbig a écrit :

Nous commencons nos nouveau projet avec MySQL :
Notre sentiment :
- En lecture => MySQL est beaucoup plus rapide
- En modification => je sais pas
- En ajout (insert) => MySQL semble beaucoup plus lent (en fait, nous
somme très decu sur ce point).

en insert de masse ? ou avec les commandes H... ?
en masse, il vaut mieux envelopper avec une transaction.

Nous n'utilisons aucun ordre HF sur mysql
MySQL avec requete INSERT

L'insert de masse de type
*
INSERT INTO MATABLE (ZON1,ZON2,ZON23) VALUES
(123,'toto',45),
(1234,'tata',415),
(5123,'titi',145),
(1523,'tutu',451)
*
ne peut pas être utilisé facilement dans le cas précis :


Le traitement importants des données d'un fichier texte ou chaque ligne
de celui ci correspond à des données stockées dans plusieurs table,
Certainnes de ces données sont redondante dans le fichier et n'ont pas
leur place dans la nouvelle base, L'import doit créer correctement les
référence commune dans des tables dictionnaires, et n'inscrire que
l'identifiant généré pour les lignes suivante faisant référence au même
données dictionnaires dans le fichier 'central'.

Bref, des traitement d'import que l'ont fait régulièrement dans des base
HF, ces memes traitements traduit en requete sql pour mysql s'effondre.

Une fois passé le cap de l'import, MySQL est plus rapide dans les
traitements de lecture/consolidation.


Petit exemple de fichier texte
Nomclient,nomreprésentant,nomsecteur
toto,riri,susu
tata,riri,susu
titi,roro,susu

Traduit
Table client table represetant table secteur
toto,1,1 1,riri 1,susu
tata,1,1 2,roro
titi,2,1

Exmple simpliste mais qui reflete assez bien la problématique :)

J'ai un peu laissé MySQL au profit de POstgresql, mais les tests que
j'avais fait à l'époque en terme d'écriture, était en faveur de HF si et
uniquement si un seul utilisateur.

Ensuite le moteur MySQL, tenait mieux la charge, et surtout tout dépend
des options activées lors de la comparaison, ne pas oublier que sous
mysql le fonctionnement est plus celui d'un HF avec :
hsecurite(2), gestion des doublons, des transactions et des journaux
(qui dans ce cas est beucoup plus lent que si on laisse les options par
défaut).


Concernant la problématique des gros imports, la méthode la plus rapide
si on va de HF vers une autre base peut être la suivante:

-copie enregistrement par enregistrement (ou par bulk) de HF vers autres
bases.
-lorsques la copie est terminée, créer les index sur la table ou les tables.
-Ensuite si on veut parser les tables, passer par des tables temporaires
et surtout on fait tout en SQL (penser à écrire les index uniquement à
la fin de la copie/écriture des enregistrements).




--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)

Daniel avait écrit le 31/10/2006 :

Vbig a écrit :

[...]

Concernant la problématique des gros imports, la méthode la plus rapide si on
va de HF vers une autre base peut être la suivante:

-copie enregistrement par enregistrement (ou par bulk) de HF vers autres
bases.

C'est quoi "bulk" ?

-lorsques la copie est terminée, créer les index sur la table ou les tables.
-Ensuite si on veut parser les tables, passer par des tables temporaires et
surtout on fait tout en SQL (penser à écrire les index uniquement à la fin de
la copie/écriture des enregistrements).

Vbig a écrit :

C'est quoi "bulk" ?

c'est quand tu traites plusieurs requètes insert en une seule.
Au lieu de :
insert into matable (col1,col2) values(1,'toto');
insert into matable (col1,col2) values(2,'tata');
insert into matable (col1,col2) values(3,'titi');
insert into matable (col1,col2) values(4,'tutu');
...
tu fais :
insert into matable (col1,col2) values
(1,'toto'),
(2,'tata'),
(3,'titi'),
(4,'tutu');

Le seul reproche que je pourrais faire à cette méthode, c'est que si on
a un problème d'intégrité dans un seul insert, c'est toute la requète
qui est refusée.




--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com