Discussion :

[Benjamin GAGNEUX]

Bonjour,

Je souhaite réaliser un logiciel multi-postes et multi-utilisateurs.
Afin de minimiser les requetes et les tranferts réseaux, je pense avoir une idée cependant je souhaiterais votre avis sur la faisabilité et la performance.

Contraintes :
- Serveur FireBird 1.5.x qui ne sera pas forcément dédié sur de petits réseaux
- La base contient une table A ayant des référencement sur plusieurs autres table.
- La table A pourra atteindre 1 million d'enregistrements.

Idée :
- réaliser une vue permettant de visualiser la table A avec ses référencements.
- atteindre la vue avec un TIBDataSet sur le client (qui permet une mise en cache de la vue).
- Filtrer le TIBDataSet en fonction des paramètres de recherches (a partir de l'image de la table A en cache).

- les Insert/Update seront réalisés via un TIBSQL.

- Lors de nouvelles recherches, une mise a jour du TIBDataSet sera faite (afin de récupérer seulement les modifications depuis la dernière mise en cache).

(Les transactions seront gérés selon les besoins)

Ceci est-il vraiment réalisable ? Ou ai-je raté quelque chose ?

Merci,

PS : Question annexe : Comment interdire les requetes trop gourmandes (revoyant trop d'information et risquant de saturé le serveur ou le réseau).

[Barbibulle]

Afin de minimiser les requetes et les tranferts réseaux

- atteindre la vue avec un TIBDataSet sur le client (qui permet une mise en cache de la vue).
- Filtrer le TIBDataSet en fonction des paramètres de recherches (a partir de l'image de la table A en cache).

PERDU !
Si vous mettez en cache ou que vous faites un filtre locale vous allez rapatrier votre million d'enregistrement et attachements à travers le réseau. Et ce à chaque recherche...

- les Insert/Update seront réalisés via un TIBSQL.

Et pourquoi ?? Vous utilisez un TIBDataSet pour la lecture et vous n'utilisez pas ses capacitées pour la mise à jours ? Ce qui veut dire qu'en faisant vos mises à jours via un composant externe il vous faudra recharger vos données se trouvant dans votre IBDataSet. On peut pas dire que ce soit performant.
Certe il y a eut un débat dans ce forum concluant que le IBSQL est plus léger qu'un IBDataSet/IBQuery/IBUpdate, mais la différence de performance est dans un cas bien particulier quand on fait des insertions massives par exemple des traitements de masse, ce qui n'est pas le traitement le plus courant. Si après ca vous devez lier les données avec les composants d'affichage, le IBSQL perd de son interret et sera même moins bien.

- Lors de nouvelles recherches, une mise a jour du TIBDataSet sera faite (afin de récupérer seulement les modifications depuis la dernière mise en cache).

(Les transactions seront gérés selon les besoins)

Bon 1millon d'enregistrements fb1.5 le supporte facilement mais c'est vrai aussi qu'il faut faire un minimum attention aux traitements/affichages.
Bannir les filtres locaux au profits de requete SQL avec des clauses where adaptées. Rammener en locale que le minimum et effectuer les recherches toujours suivant un indexe (sauf si vous devez ballayer toute la table). Et surtout bien comprendre le fonctionnement des transactions. Pour les mises à jours (update/insert) faire en sorte que la transaction soit la plus courte possible.
Le probleme de mettre en cache les mises à jours localement c'est qu'en environnement multiUser, vous allez avoir à résoudre vous même les problèmes d'accès conccurent.

Pour conclure, avant de faire des plans sur la comète et de parler optimisation en voulant prendre les outils les plus performants faite l'inventaire de vos traitements et grosses requetes de traitement / affichage.

Créez votre base et surtout insérez dedans votre million d'enregistrements, ainsi vous pourrez juger par vous même de la performance de vos requete (avec un analyseur de requete). En temps d'exécution temps de fetch et aussi le nombre de lecture/insertion effacement/table, et savoir si un indexe est utilisé ou pas.

Un SGBD est réalisé et optimisé pour la manipulation des données, recherche etc... Il faut respecter certaines règles de bon sens et tout se passe bien. Le plus souvant quand on ne l'utilise pas 'normalement' on ne fait que dégrader les performances.

Voilà ça c'était pour parler du cas générale. Pour les cas particuliers il n'y a pas de solution générale et donc c'est à étudier au cas par cas.

[Benjamin GAGNEUX]

Merci Barbibulle, je commence à y voir plus clair.

Afin de minimiser les requetes et les tranferts réseaux

- atteindre la vue avec un TIBDataSet sur le client (qui permet une mise en cache de la vue).
- Filtrer le TIBDataSet en fonction des paramètres de recherches (a partir de l'image de la table A en cache).

PERDU !
Si vous mettez en cache ou que vous faites un filtre locale vous allez rapatrier votre million d'enregistrement et attachements à travers le réseau. Et ce à chaque recherche...

Dommage...
J'avais imaginé un peu un MVC à la smallTalk (mais surtout utiliser pour ma part en java) :
Le Modele contient les données c'est la base de données.
La Vue modifie les données sous condition et les affiches.
Le Controleur vérifie les données et leurs cohérence avant de les ajouter au Modele.

Je ne voulais utiliser le TIBDataSet seulement dans le role de la Vue. Mais apparemment c'est pas possible et je ne souhaite pas voir le rapatriment total des données a chaque fois ou alors autant utiliser le TIBSQL que j'utilisais avant.


En faite, ce que je voudrais récupérer c'est un listing correspondant à certains critères du style : nom commencant par ..., Date d'entrée etc ...

Mais dans ce cas, il semblerait que le TIBDataSet soit obliger de rapatrier toutes les données correspondantes a chaque fois...

- les Insert/Update seront réalisés via un TIBSQL.

Et pourquoi ??

Les insert et update agissent sur plusieurs tables sous conditions. Si les cohérences sont respectées d'un bout à l'autre de la transaction, alors l'ajout dans la table principale est possible (mais pas obligatoire).

c'est pourquoi j'ai préféré utiliser les TIBSQL (dont je maitrise mieux le fonctionnement) qui semblent mieux correspondre à plusieurs ajouts dans une même transaction.



Conclusion :

Je crois comprendre qu'en fait le TIBDataSet n'est pas adapté à mes besoins (malgré ses nombreux avantages). Il faut que j'utilise un TIBSQL qui rapatriera tout le résultat a chaque fois mais qui résoudra entre autres les problèmes d'accès concurrents.

Mais alors, il me faut un moyen d'empecher le rapatriment de grandes parties de la table pour motif de manque de précision dans la recherche.
Surtout lorsqu'il s'agit de recherche sur le descriptif (200 caract.), je ne souhaite pas que l'utilisateur rapatrie disons 3/4 millions d'enregistrements après tous les avoir balayer. Temps de la requete pas terrible.
Il faut que je trouve une parade ... une astuce ou autre car apparement c'est pas prévu à la base dans FireBird.


[Info]
Je réalise une deuxième version d'un de mes logiciels, et j'ai souhaité migrer de ADO (Access2000) à IBX (FireBird). Je m'étais rendu compte que ADO (et Access) c'est plutot lourd et en plus pour le réseau il y a mieux qu'un partage de répertoire. D'autre part, plus de contraintes: des réseaux plus grands, plus de données, plus d'exportation de données.
[/Info]

Merci,

[Barbibulle]

je viens de perdre mon message assez long de réponse.
Je fais essayer d'en faire un résumer

Je ne voulais utiliser le TIBDataSet seulement dans le role de la Vue. Mais apparemment c'est pas possible et je ne souhaite pas voir le rapatriment total des données a chaque fois ou alors autant utiliser le TIBSQL que j'utilisais avant.


En faite, ce que je voudrais récupérer c'est un listing correspondant à certains critères du style : nom commencant par ..., Date d'entrée etc ...

Mais dans ce cas, il semblerait que le TIBDataSet soit obliger de rapatrier toutes les données correspondantes a chaque fois...

Non vous m'avez mal compris,
Que vous utilisiez le IBDataSet ou le ISQL il faut éviter le rapatriement total en locale de votre table (donc ne pas faire un select * from matable.
Ce dont je parlais dans le TIBDataSet c'est le filtrage local qui peut etre utilisé pour des raisons de facilité mais le plus souvant celà oblige le rapatriement de toute la requete (et donc si vous avez fait un select * from matable; rapatriera toute votretable (sous certaines conditions))!
Mais si vous n'utilisez pas de filtrage local (donc si vous utilisez des ordres SQL adaptés ) vous n'aurez pas ce problemes.

De plus il faut savoir que ce les composants IB sont bien optimisés pour les applications client/serveur. Par exemple si vous faites un select * from matable; le résultat et l'affichage sera immédiat même si votre table contient des millions d'enregistrements. Pourquoi ? simplement parce que la requete en elle même est très rapide (la lecture se faisant dans l'ordre naturel de votre table) et elle va renvoyer les X premiers résultats (remplissage du buffer). Ce qui veux dire qu'il n'y a pas trop d'info qui ont transité sur le réseau. Si vous faites des next ou que vous utilisez l'ascenseur du DBGrid les données suivantes vont etres demandées au serveur (fetch) ce qui est rapide aussi, mais par contre faire un last va boucler afin de rapatrier et buffeuriser toute les données (et donc toute votre table aura transitée par le réseau).
NB : Attention certain composants grilles de données ont un comportement par défaut qui obligent le rapatriement de toutes les données de la requete.

Les insert et update agissent sur plusieurs tables sous conditions. Si les cohérences sont respectées d'un bout à l'autre de la transaction, alors l'ajout dans la table principale est possible (mais pas obligatoire).

c'est pourquoi j'ai préféré utiliser les TIBSQL (dont je maitrise mieux le fonctionnement) qui semblent mieux correspondre à plusieurs ajouts dans une même transaction.

Je ne vois pas ou est le pb avec les IBDataSet.
Quand j'ai des controles complexes à faire j'utilise une PS, ce qui a le mérite d'etre plus rapide, plus facile et réduit le trafic réseau.

Conclusion :

Je crois comprendre qu'en fait le TIBDataSet n'est pas adapté à mes besoins (malgré ses nombreux avantages). Il faut que j'utilise un TIBSQL qui rapatriera tout le résultat a chaque fois mais qui résoudra entre autres les problèmes d'accès concurrents.

Non cf explications plus haut

Mais alors, il me faut un moyen d'empecher le rapatriment de grandes parties de la table pour motif de manque de précision dans la recherche.
Surtout lorsqu'il s'agit de recherche sur le descriptif (200 caract.), je ne souhaite pas que l'utilisateur rapatrie disons 3/4 millions d'enregistrements après tous les avoir balayer. Temps de la requete pas terrible.
Il faut que je trouve une parade ... une astuce ou autre car apparement c'est pas prévu à la base dans FireBird.

Faux

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select first 50 colonne1, colonne2 from matable ...;

limitera le résultat au 50 premiers enregistrements. Celà limitera donc le trafic réseau et les requetes qui selectionnent trop de choses.
Mais celà n'empèchera pas une requete qui ne ramène rien ou peux d'enregistrements d'être lourde. Il faut dissocier le quantité de données rapatriée de la quantité de données lue par le serveur pour trouver ces données.

[Benjamin GAGNEUX]

En fait, j'ai développé un composant Grille décendant de TStringGrid avec pas mal d'options. Donc a partir de ce moment la, le parcours du résultat de la requete doit etre intégral. Et il ne sera pas facilement possible de garder une image local de la requete.

De plus, si le rapatriment de quelques millions d'enregistrements ne risque pas de provoquer de grands ralentissements, autant ne pas compliquer les choses.

Faux

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select first 50 colonne1, colonne2 from matable ...;

J'ai vu cette technique sur d'autres posts. Mais j'aurais préféré une technique qui bloque le balayage de la table lorsque un nombre de résultat est atteint.
Alors que cette technique balaye toute la table (si pas d'index correspondant tel que recherche d'un mot dans un descriptif de 200 caractères) avant de limite le résultat pour le client.

Mais puisque les requetes, même lourdes et suseptible de renvoyer des millions d'enregistrements, semblent etre rapide, je pense opter pour cette solution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select first n colonne1, colonne2 from matable ...;

Si le résultat est inférieur à n, j'affiche le résultat.
Si le résultat est égal à n,je demande de préciser la recherche car il existe peut etre plus que n enregistrements.

Ainsi, je n'économise pas trop le serveur (mais vu ce qu'il y a marqué en caractéristique technique dans l'aide InterBase je suis tranquil), mais j'économise le réseau en limitant l'envoie de liste trop fourni (et inexploitable pour l'utilisateur).

La technique des PS et des vues semble très intéressante car plus rapide et économie du traffic réseau.

Je vais me lancer dans une séries de test afin de mettre en pratique tout ceci.

Merci beaucoups Barbibulle pour toutes ces précisions !

PS : désolé pour les phrases a ralonge je ne suis pas bien réveillé aujourd'hui...