Discussion :

[fbe66]

bonjour à tous,

J'ai créé une base Hyperfile C/S hébergée sur le web. Cette base sera multi-site et multi-client, avec des quantités importantes dans certains fichiers. Je souhaite accéder à partir d'un poste client à ces données, et l'accés est souvent long (24 s. pour afficher le planning du jour).

Afin d'alléger le traitement en local, est-il possible de créer une vue sur le serveur via un trigger, et de l'afficher en local.

Y a t'il une solution autre pour ce principe ?

Merci à tous..

[Atsibat]

Dans la configuration que vous envisagez la solution est de passer par un autre SGDB. avec un accès natif si vous avez utilisé beaucoup de databinding ou de fonctions H***

Faites un test avec un bon SGDB gratuit type PostgreSQL et dites moi si votre temps est toujours aussi misérable.

Note : préférez PostgreSQL à MySQL car la licence n'est pas du tout la même.

Bon dev

[lolob84]

Bonjour,

Je ne suis pas certain que le fait de changer de SGBD soit la première solution à envisager :
J'utilise des volumes conséquents de données sur des serveurs distants sans pour autant avoir forcément des accès très lents (plusieurs dizaine de milliers de lignes).Maintenant, tout dépend de la façon dont on accède aux données :
Préférez toujours des requètes et des méthodes ensemblistes pour rapatrier les données (typiquement les fonctions du type hlitrecherche, et en général les commandes h* impliquant des lectures enregistrement par enregistrement sont à proscrire, sauf dans le cas où l'on souhaite travailler à l'enregistrement justement. une bonne requete SQL bien construite peut vous donner des résultats en terme de performances très convenable, même en HyperFileSQL.
Evitez les constructions de requetes dans le code au maximum. Pour une raison que j'ignore, créer ou ecrire du code SQL dans un objet requete de l'editeur de requete de l'outil permet d'obtenir de meilleurs résultats, sans compter la complétion et le databinding fonctionnel dans ce cas sur la requête générée.

En clair vérifiez si votre accès à ces données est optimisé (clés suffisantes et nécessaires, index et statistiques serveur à jour, meilleure méthode d'accès aux données). Vous devriez obtenir des temps d'accès corrects

N'hésitez pas non plus à utiliser les outils d'audit et d'optimisation de l'outil, ils ne sont pas parfait mais peuvent vous donner des pistes sur ce qui provoquent le ralentissement. (dernier exemple recontré lors d'un audit, une table fichier basé sur une requete construite en automatique avait des temps d'accès élevé aux données.L'outil d'audit de code en éxécution de Windev nous a montré que c'était le temps de chargement de la table qui était long, pas l'accès aux données. Nous l'avons remplacée par une table mémoire chargée par programmation, toujours basée sur la même requête et divisé par trois les temps d'accés. Ce n'est pas une règle systématique, mais dans ce contexte, ça a été efficace).

Bon courage.

Laurent

Bon courage.

[Atsibat]

Bonjour,

La création d'une vue sur le serveur (actualisée via un trigger) serait valable si le planning portait sur des jointures complexes, encore plus valable si les jointures comportent des fonctions de calcul. Mais pour un planning c'est rarement le cas. Il est plus logique de suivre les pistes données par lolo84. Elles sont toutes bonnes à suivre et c'est probablement par là qu'il faut commencer. ( optimiser la requête, optimiser les index)

@lolo84 : plusieurs dizaines de miliers de lignes c'est une toute petite base de donnée. si c'est le cas ici je ma suis fourvoyé, pas la peine de changer de SGDB, je pensais qu'il s'agissait d'un vrai gros volume

(Lorsqu'on parle de volume de donnée important on parle de plusieurs millions de lignes. Dans ce cas je vous assure que les bases de type fichier comme HF même en CS atteignent très vite leurs limites)


Une autre piste est la disponibilité de votre serveur, vous pouvez peut-êtrefaire un test avec l'hébergement PC-SOFT :

http://www.pcsoft.fr/webdev/hebergement.htm

Enfin si vous avez un doute vous pouvez aussi nous envoyer la requête
Bon dev