Discussion :

[Phoenix311]

Bonjour à tous,

J'ai une question à laquelle je n'ai pas vraiment de réponses. J'ai une appli qui tourne en client serveur. Comme beaucoup d'applications, à terme, je vais avoir pas mal d'enregistrements (je pense que ça peu arriver à 10 000 voir 20 000 enregistrements). Donc j'ai pensé à mettre en place le système suivant, qu'en pensez vous :

- Les utilisateurs travaillent sur des tables qui sont filtrés par un paramètre (pas d'intérêt de tout afficher en permanence). L'utilisateur charge les données (par exemple 500 enregistrements que je met en table mémoire) et après je travaille avec des tableactivefiltre (qui est du coup instantané et agréable pour l'utilisateur. en effet, la moindre latence dans des filtre de recherche est à terme pénible).
J'ai peur qu'à terme, la requete soit de plus en plus longue à afficher les données, vu qu'elle va parcourir TOUT le fichier et faire ressortir que les données qui sont filtrées par le paramétre. Je voulais donc créer un fichier archive pour copier les enregistrements qui ne servent plus dans ce fichier et ainsi avoir un fichier sur lesquels les utilisateurs vont travaillé vivant et avec peu d'enregsitrements. Si l'utilisateurs souhaite des statistiques sur les deux fichiers (archive et fichier courant) je ferai une requête union.

Qu'est ce que vous pensez de ce système ?

Merci pour votre expertise

PS : Je travaille avec des requêtes qui peuvent regrouper jusqu'à 10 fichiers différents, donc avec plus de 3000, 4000 enregistrements on commence à avoir un peu de temps de réponse déjà...

[serendib]

Bonjour à tous,

(je pense que ça peu arriver à 10 000 voir 20 000 enregistrements)
Je travaille avec des requêtes qui peuvent regrouper jusqu'à 10 fichiers différents, donc avec plus de 3000, 4000 enregistrements...

Bah c'est pas ce que j'appelle des gros fichiers, c'est même très courant.
Le problème est ailleurs à mon humble avis...

[Nicolas_Jeanneau]

Bonjour,

pour ma part, je travaille avec des tables de plusieurs centaines de milliers de lignes et je n'ai pas de ralentissement. Il faut que tu travailles sur les indexes, les requêtes etc ... afin d'avoir de bons temps de réponses. L'optimisation passe par là et si les requêtes sont bien formulées, le résultat est rapide.

à bientôt,

Nicolas

[Phoenix311]

Bonjour,

Merci beaucoup pour vos réponses. Je me doutais que vous me diriez que c'est pas des gros fichiers ^^

Quand je parle de rapidité, je veux que le chargement se fasse en 1 à 2 secondes maximum vu que c'est un outil qui est susceptible d'être utilisé très régulièrement, que l'utilisateur ne se lasse pas.. Vous arrivez à avoir ces temps de réponse avec des très gros fichiers ?

Si oui, que dois faire pour améliorer mes requêtes ? J'ai une très grosse requête avec 10 fichiers (peut être même plus). Je travaille avec des clés primaires et des clés étrangères. J'ai un fichier dans lequel j'ai quelques champs textes et des clés étrangères (pour faire le lien avec les autres fichiers). Quand je fais ma requête je met les champs de mon fichier principal (avec les clé étrangères) et je met également les champs des fichiers liés (sans mettre la clé primaire).

Ce n'est pas suffisant ?

Quand vous dites il faut travailler sur les indexés, ça veut dire quoi exactement ?

Merci pour vos retour !

[tbc92]

Bonjour,
10 fichiers dans une requête, ça commence à faire une belle requête.
Il faut donc s'assurer qu'il y a les index adaptés dans les fichiers.
L'autre formalité à accomplir, c'est de faire des hReindexe() régulièrement.
Et comme ton problème, c'est plus dans la rapidité de lecture que dans la rapidité d'écriture, il faut mettre les bons paramètres dans la réindexation.

La même requête peut mettre 10 secondes à s'exécuter dans un environnement 'brut', puis 2 secondes après réindexation.

[Younes YAICH]

Bonjour,

pour ma part, je travaille avec des tables de plusieurs centaines de milliers de lignes et je n'ai pas de ralentissement. Il faut que tu travailles sur les indexes, les requêtes etc ... afin d'avoir de bons temps de réponses. L'optimisation passe par là et si les requêtes sont bien formulées, le résultat est rapide.

à bientôt,

Nicolas

Est-ce la même chose s'applique sur une application installée dans un serveur, et les client se connectent à distant, ,est-ce qu'on peut avoir un bon temps de réponse.

Merci d'avance

[tbc92]

Est-ce la même chose s'applique sur une application installée dans un serveur, et les client se connectent à distant, ,est-ce qu'on peut avoir un bon temps de réponse.

Merci d'avance

Quand on est en réseau, le temps d'affichage d'une requête peut se décomposer ainsi :
- Envoi de la question au serveur : négligeable
- Traitement de la requête, jointure entre les table, tri, sous totaux : tout ce temps est strictement le même qu'on soit en local ou en réseau.
- Envoi de la réponse du serveur vers le poste client : Et là, si on doit renvoyer de gros volumes, et si le réseau est lent, ça peut être long.
Un moyen de tester cela, c'est de faire un fichier tout simple, sans jointure et demander à afficher ce fichier dans une table, via le réseau.

Pour contourner le problème, en Windev, on peut passer par des tables fichiers, avec les paramétrages adéquats.
Dès que le programme a rapatrié les 20 ou 30 premières lignes, il rend la main à l'utilisateur. Et la récupération des enregistrements suivants continue en tache de fond.