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 ?
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
Peux tu préciser ce que tu entends par désigner les index en fonction de ce que l'on veut faire.
Un SGBD intelligent utilisera les bons index en fonction de ta requête.
(alors qu'avec des fonctions HLitRecherche, les index sont explicitement nommés)
"Explicitement nommés" => tu veux dire avoir un nom explicite, ou qu'on précise le nom de l'index dans le HlitRecherche ?
si c'est un nom explicite, quand tu défini tes index, tu peux très bien leur donner aussi des noms explicites lors du CREATE INDEX si c'est "préciser le nom lors de l'appel du Hlitrecherche", ca rejoint ce que je disais plus haut, un sgbd intelligent, analyse ton ordre SQL est utilise les index les plus adaptés.
Cdt.
VincentC
patrice a formulé la demande :
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
Peux tu préciser ce que tu entends par désigner les index en fonction
de ce que l'on veut faire.
Un SGBD intelligent utilisera les bons index en fonction de ta requête.
(alors qu'avec des fonctions HLitRecherche, les index sont
explicitement nommés)
"Explicitement nommés" => tu veux dire avoir un nom explicite, ou
qu'on précise le nom de l'index dans le HlitRecherche ?
si c'est un nom explicite, quand tu défini tes index, tu peux très bien
leur donner aussi des noms explicites lors du CREATE INDEX
si c'est "préciser le nom lors de l'appel du Hlitrecherche", ca rejoint
ce que je disais plus haut, un sgbd intelligent, analyse ton ordre SQL
est utilise les index les plus adaptés.
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
Peux tu préciser ce que tu entends par désigner les index en fonction de ce que l'on veut faire.
Un SGBD intelligent utilisera les bons index en fonction de ta requête.
(alors qu'avec des fonctions HLitRecherche, les index sont explicitement nommés)
"Explicitement nommés" => tu veux dire avoir un nom explicite, ou qu'on précise le nom de l'index dans le HlitRecherche ?
si c'est un nom explicite, quand tu défini tes index, tu peux très bien leur donner aussi des noms explicites lors du CREATE INDEX si c'est "préciser le nom lors de l'appel du Hlitrecherche", ca rejoint ce que je disais plus haut, un sgbd intelligent, analyse ton ordre SQL est utilise les index les plus adaptés.
Cdt.
VincentC
patrice
"VincentC" a écrit dans le message de news:
patrice a formulé la demande : > 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
Peux tu préciser ce que tu entends par désigner les index en fonction de ce que l'on veut faire.
créer les indexs qui correspondent au clause where ou order by les + gourmandes.
Un SGBD intelligent utilisera les bons index en fonction de ta requête.
pour HF il faut deux conditions pour qu'il utilise un index : 1) il faut qu'un index existe 2) il faut que les stats soient calculées pour qu'il sache que cet index est meilleur qu'un autre ces 2 choses sont à faire manuellement, rien d'automatique la dedans. pour moi HF est autant un SGBD que le pilote ODBC des fichiers textes.
> (alors qu'avec des fonctions HLitRecherche, les index sont > explicitement nommés) "Explicitement nommés" => tu veux dire avoir un nom explicite, ou qu'on précise le nom de l'index dans le HlitRecherche ?
Quand on voie un index dans l'analyse, en cherchant dans le code tous les Hlitrecherche avec le nom de cet index, on peut savoir s'il est utilisé et pourquoi.
"VincentC" <VNO.SPAM_perso@free.Fr> a écrit dans le message de
news:mn.fcb77d6a37e133d1.48802@free.Fr...
patrice a formulé la demande :
> 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
Peux tu préciser ce que tu entends par désigner les index en fonction
de ce que l'on veut faire.
créer les indexs qui correspondent au clause where ou order by les +
gourmandes.
Un SGBD intelligent utilisera les bons index en fonction de ta requête.
pour HF il faut deux conditions pour qu'il utilise un index :
1) il faut qu'un index existe
2) il faut que les stats soient calculées pour qu'il sache que cet index
est meilleur qu'un autre
ces 2 choses sont à faire manuellement, rien d'automatique la dedans.
pour moi HF est autant un SGBD que le pilote ODBC des fichiers textes.
> (alors qu'avec des fonctions HLitRecherche, les index sont
> explicitement nommés)
"Explicitement nommés" => tu veux dire avoir un nom explicite, ou
qu'on précise le nom de l'index dans le HlitRecherche ?
Quand on voie un index dans l'analyse, en cherchant dans le code tous les
Hlitrecherche avec le nom de cet index, on peut savoir s'il est utilisé et
pourquoi.
patrice a formulé la demande : > 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
Peux tu préciser ce que tu entends par désigner les index en fonction de ce que l'on veut faire.
créer les indexs qui correspondent au clause where ou order by les + gourmandes.
Un SGBD intelligent utilisera les bons index en fonction de ta requête.
pour HF il faut deux conditions pour qu'il utilise un index : 1) il faut qu'un index existe 2) il faut que les stats soient calculées pour qu'il sache que cet index est meilleur qu'un autre ces 2 choses sont à faire manuellement, rien d'automatique la dedans. pour moi HF est autant un SGBD que le pilote ODBC des fichiers textes.
> (alors qu'avec des fonctions HLitRecherche, les index sont > explicitement nommés) "Explicitement nommés" => tu veux dire avoir un nom explicite, ou qu'on précise le nom de l'index dans le HlitRecherche ?
Quand on voie un index dans l'analyse, en cherchant dans le code tous les Hlitrecherche avec le nom de cet index, on peut savoir s'il est utilisé et pourquoi.
VincentC
patrice a écrit :
ces 2 choses sont à faire manuellement, rien d'automatique la dedans. pour moi HF est autant un SGBD que le pilote ODBC des fichiers textes.
Pour préciser, quand je parlais de SGBD intelligent, je ne parlais pas de HF C/S.
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
Je pensé que tu parlais de l'utilisation de requêtes SQL indépendamment du nom du SGBD et donc non spécifiquement pour HF. C'est pour ça que je n'étais pas trop d'accord.
Pour moi l'utilisation de requête SQL permet de faciliter la récupération de certaines infos (notamment pour des stats). Je trouve plus "propre" de faire une requete liant x tables plutôt que de faire des HFiltre ou HLitRecherche imbriqué et d'incrémenter manuellement des compteurs
Maintenant, elle prépare indirectement à la migration vers un SGBD plus standart.
Cdt.
VincentC
patrice a écrit :
ces 2 choses sont à faire manuellement, rien d'automatique la dedans.
pour moi HF est autant un SGBD que le pilote ODBC des fichiers textes.
Pour préciser, quand je parlais de SGBD intelligent, je ne parlais pas
de HF C/S.
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
Je pensé que tu parlais de l'utilisation de requêtes SQL indépendamment
du nom du SGBD et donc non spécifiquement pour HF. C'est pour ça que je
n'étais pas trop d'accord.
Pour moi l'utilisation de requête SQL permet de faciliter la
récupération de certaines infos (notamment pour des stats). Je trouve
plus "propre" de faire une requete liant x tables plutôt que de faire
des HFiltre ou HLitRecherche imbriqué et d'incrémenter manuellement des
compteurs
Maintenant, elle prépare indirectement à la migration vers un SGBD plus
standart.
ces 2 choses sont à faire manuellement, rien d'automatique la dedans. pour moi HF est autant un SGBD que le pilote ODBC des fichiers textes.
Pour préciser, quand je parlais de SGBD intelligent, je ne parlais pas de HF C/S.
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
Je pensé que tu parlais de l'utilisation de requêtes SQL indépendamment du nom du SGBD et donc non spécifiquement pour HF. C'est pour ça que je n'étais pas trop d'accord.
Pour moi l'utilisation de requête SQL permet de faciliter la récupération de certaines infos (notamment pour des stats). Je trouve plus "propre" de faire une requete liant x tables plutôt que de faire des HFiltre ou HLitRecherche imbriqué et d'incrémenter manuellement des compteurs
Maintenant, elle prépare indirectement à la migration vers un SGBD plus standart.
