Discussion :

[mina24]

Bonjour,
J'ai une table produit très volumineuse 400 000 enregistrements(64 champs, clé primaire (VARCHAR)). J'utilise le composant zquery pour y accéder ;
produit.open et produit.refresh prennent un temps fous pour s’exécuter (plus d'une minute).
J'ai cherché sur le forum une méthode pour accélérer l'accès; J'ai trouvé qu'on pouvait jouer sur la propriété FetchRow mais ça n'a rien donné. Est-ce que je n'ai pas su le faire (j'ai juste mis fetchrow à 200 au lieu de 0) ou bien y aurait-il une autre méthode ?
Merci.

[cantador]

Bonjour,

oui, c'est étonnant pour 400 000 enregistrements.
bon, c'est vrai, il y a beaucoup de champs..
il faudrait connaître la taille totale de la table.
Pour ma part, j'ouvre sans problème des tables de 1 giga 2.

pourquoi avoir créé une clé primaire en VARCHAR ?

[mina24]

il faudrait connaître la taille totale de la table.

La taille globale de la base est de 110 352 KO.

pourquoi avoir créé une clé primaire en VARCHAR ?

On a créer la base de donnée il y a bien longtemps (1998) paradox

[cantador]

La taille globale de la base est de 110 352 KO.

c'est tout petit

On a créer la base de donnée il y a bien longtemps (1998) paradox

alors, il est temps de migrer tout ça vers une base SQL plus moderne et pourquoi pas gratuite
comme FireBird qui supporte des trillions de données et en profiter également pour
créer une clé primaire en integer (en auto incrémentale) et de faire les relations avec ce champ
ce qui n'empêche nullement d'avoir d'autres champs avec des propriétés différentes pouvant être utilisées dans les requêtes.
bref, un retour aux sources avec un peu de modélisation..

bon courage

@bientôt

[mina24]

c'est tout petit
alors, il est temps de migrer tout ça vers une base SQL plus moderne et pourquoi pas gratuite
comme FireBird qui supporte des trillions de données

Justement comme l'indique l'intitulé de ma discussion là je suis avec FireBird (c'est la création originel de ma base qui c'est faite il y a bien longtemps avec paradox) Vous n'aurez pas une solution pour régler la lenteur.

[seabs]

Bonjour,

Je n'ai pas très bien compris.

Tu dis que la base a été créée avec Paradox et maintenant, tu utilises Firefird.

Tu peux expliquer comment la base de Paradox est passée dans Firebird. Il s'agit d'une importation avec un outil ou d'un transfert manuel.

En effet, @cantador a raison, il s'agit d'une base toute petite et rien ne justifie de tels délais.

Pour la lecture de ta base, tu emploies un zQuery ce n'est pas la taille de la table qui compte, mais le nombre d'enregistrement que tu lis. Tu as fait des essais en ne lisant que 100 ou 200 enregistrements. D'ailleurs, je ne vois aucune utilité de lire avec une seule requête 400 000 enregistrements.

En clair, pour t'aider, il faut plus d'explications. D'ailleurs, la charte du forum est très clair sur ce point.

A+

[mina24]

Bonjour,

Je n'ai pas très bien compris.

Tu dis que la base a été créée avec Paradox et maintenant, tu utilises Firefird.

Tu peux expliquer comment la base de Paradox est passée dans Firebird. Il s'agit d'une importation avec un outil ou d'un transfert manuel.

J'ai fais une migration manuel vers firebird .

En effet, @cantador a raison, il s'agit d'une base toute petite et rien ne justifie de tels délais.

Justement c'est pour cela que je demande de l'aide.

Pour la lecture de ta base, tu emploies un zQuery ce n'est pas la taille de la table qui compte, mais le nombre d'enregistrement que tu lis. Tu as fait des essais en ne lisant que 100 ou 200 enregistrements. D'ailleurs, je ne vois aucune utilité de lire avec une seule requête 400 000 enregistrements.

pour pouvoir choisir un des produits il y a une case ou l'on peut faire une recherche du produit soit par code soit par désignation j'utilise locate qui fonctionne très bien, la recherce est rapide la lenteur est comme je l'ai dis au niveau de open et refresh.

[cantador]

@mina24:

je vérifierai s'il n'y a pas des index (trop..) de déclarés..
je commencerai par modifier la clé primaire (comme indiqué précédemment)
puis en tout état de cause, je ferai un BackUp/Restore de la base.

et enfin, un test d'ouverture..

@seabs

D'ailleurs, je ne vois aucune utilité de lire avec une seule requête 400 000 enregistrements.

pas nécessairement, tout dépend de ce que tu souhaites faire.
en cas de recherche incrémentale, c'est utile par exemple.

[qi130]

le zquery est utilisé comment? le résultat de la requête est exploité comment ?

quand tu dis

Code :

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

produit.open

"produit" correspond à quoi (quel composant?).

Bref, quelques précisions s'imposent....

Il y a aussi ce tuto, à toutes fins utiles : http://serge-girard.developpez.com/t.../temp/ZeosDBO/

[mina24]

le zquery est utilisé comment? le résultat de la requête est exploité comment ?

quand tu dis

Code :

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

produit.open

"produit" correspond à quoi (quel composant?).

Bref, quelques précisions s'imposent....

Il y a aussi ce tuto, à toutes fins utiles : http://serge-girard.developpez.com/t.../temp/ZeosDBO/

Au fait produit c'est le name de zquery dont le sql est

Code :

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

select clé,champs1,... from table

avec IndexeFieldName est clé Asc. j'utilise un dbgrid pour l'affichage.

[ShaiLeTroll]

Aucun être humain peut assimiler une grille 400 000 enregistrements : on en a parlé dans accélérer l'affichage des donnée dans un Dbgrid.
Evidemment à l'époque de Paradox et le TTable, le Open était instantané et affichait le début de fichier
En SQL avec un SGBD distant, il ne faut surtout plus pratiqué cela !

C'est contre productif de récupérer 400 000 enregistrement si on final, l'utilisateur voulait trouver une liste de 10 articles correspondant à ces critères
Tu devrais repenser ta recherche, par défaut, cela n'affiche rien
l'utilisateur choisi ses critères et mots clés,
A partir de cela tu génères dynamiquement un SELECT WHERE pour ne récupérer que les données utiles

Attention, sur les mots clés, éviter un LIKE sur moins de 3 caractères (j'ai eu ce problème sur une table Patient de la même taille, avec des noms de familles comme "Ly", "Y" que le LIKE n'aimaient pas du tout ...)


FetchRow aurait du avoir un impact, cela permet de récupérer lot par lot, les enregistrements de l'ensemble, dans ton cas les 200 premiers
Lors que le Next arrive à la fin du lot des 200, cela provoque la récupération des 200 suivants et ainsi de suite

Un outil comme DBExplorer, IBExpert avec le même SQL l'ouvre en combien de temps


Une grille contenant un footer (TMS, DevExpress) affichant des totaux force une lecture totale des enregistrements ce qui fait perdre tout l'avantage du FetchRow
Cela provoque le Next et donc la récupération totale des données, et une minute pour récupérer 400 000 enregistrements, cela n'a rien de surprenant (traitement par le serveur, trafic réseau, traitement par le client)

Tu utilises bien juste une TDBGrid ?
Tu n'as pas un code qui fait une boucle Next
le RecordCount était souvent faux en mode Fetch, il est souvent un multiple de la valeur du fetch

Sinon 400 000, cela n'est pas "très volumineux", oui en Paradox cela aurait un peu de mal mais sous FireBird cela n'a rien d'extraordinaire, c'est juste un peu conséquent.
Sous MySQL 4.1, je suis monté à 10 000 000 d'enregistrements en 2012 (depuis, je ne travaille plus dessus mais cela a du monter massivement), sur une ouverture simple sans tri avec FetchRow, instantané, par contre dès que l'on ajoutait un WHERE LIKE (même avec l'index, le LIKE c'était lent)
Sous Oracle, je manipule des tables avec plusieurs millions d'enregistrement, la plus grosse va franchir les 500 000 000 d'enregistrements dans quelques semaines.
Une ouverture simple sans tri c'est à dire SELECT * FROM MaTable avec un FetchRow est instantané (environ 40ms que ce soit pour les 25rows en Delphi et 500rows sous TOAD)
Si tu ajoutes un ORDER BY sur un index, cela passe à 2-3 secondes pour les 500 premiers

Si j'ai le malheur de mettre une grille TcxGrid avec footer, c'est soit plusieurs heures de chargement ou surtout un plantage lamentable (que cela soit Delphi ou TOAD)

[mina24]

je ferai un BackUp/Restore de la base.
et enfin, un test d'ouverture..
pas nécessairement, tout dépend de ce que tu souhaites faire.
en cas de recherche incrémentale, c'est utile par exemple.

J' ai fais un Backup/Restore ça n'a rien améliorer, la je suis entrain de faire des recherche sur la "recherche incrémentale" un concept que je ne connais pas.
Merci à vous @ShailleTroll pour toutes vos explications , je vais voir tout ça et je vous tiendrais au courant.

[cantador]

@mina24 :



je viens de faire ce test avec un TIboquery (que j'affectionne particulièrement), un TDBGrid et une table Firebird (2.5) contenant 42 champs et
423884 enregistrements, une clé primaire auto-incrémentale et deux index secondaires.

mesures prises à la volée..

avec AutoFetchAll à false
un clic sur ouverture et la table s'ouvre en 0.5 s
un clic sur last et la table se cale en 10 s

avec AutoFetchAll à true
un clic sur ouverture et la table s'ouvre en 12 s
un clic sur last et la table se cale en 1 s

ce test devrait te rassurer et permettre la poursuite de la réflexion..

@+

[mina24]

Merci @Contadore ,vous m'encouragez j'y travail

[cantador]

j'ai évoqué précédemment la "recherche incrémentale" car je la pratique souvent.
avec le TcxGrid elle est intégrée nativement dans ce composant.
mais comme le souligne ShaiLeTroll, les temps s'allongent !
en effet, le TcxGrid, certes très puissant possédant, un nombre important de propriétés utiles
est aussi très gourmand.
et cette recherche présente un intérêt dès l'instant où un maximum d'informations est affichée..
dans ce contexte, on peut difficilement dépasser les 100 000 enregistrements avec un TcxGrid pour mettre en place
une recherche incrémentale..
et après avoir pris aussi la précaution de retirer les filtres des colonnes, et le GroupbyBox.
en revanche, le TDBGrid est plus pauvre, mais beaucoup plus léger.

si on veut, se trouver dans la même situation que AutoFetchAll à true et avoir un affichage plus rapide avec un TcxGrid
il faut utiliser la propriété GridMode à true du DataModeController.

@+

[mina24]

Merci pour vos repenses.
j'ai testé zquery.open sans le tdbgrid c'est aussi lent si ce n'est plus.

si on veut, se trouver dans la même situation que AutoFetchAll à true et avoir un affichage plus rapide avec un TcxGrid
il faut utiliser la propriété GridMode à true du DataModeController.
@+

Aussi j'ai essayé avec TcxGrid c'est aussi lent j'ai remarquer aussi si je fais un drag colonne pour Le group by C'est aussi trés lent
pas comme j'ai l’habitude avec paradox.
Je pense que ça a relation peut être avec les propriétés de Tzquery?????????

[qi130]

Il faudra vérifier le paramètre pagesize de la base et le comparer au poids théorique d'une ligne de la table produit et l'ajuster en conséquence.
En effet, si une ligne ne tient pas dans 1 page, il faudra lire 2 pages pour chaque ligne.
C'est à étudier de près, surtout avec beaucoup de colonnes en varchar, et/ou avec des charsets nécessitant plusieurs octets pour chaque caractère.
Rappel, pour un champ varchar, 2 octets supplémentaires sont physiquement utilisés pour mentionner la longueur utilisée.

Très certainement, la PK en varchar génère beaucoup de modifications sur l'index qui gère cette PK à chaque ajout. Puis, lors du open, il est demandé une lecture séquentielle selon la PK, mais l'ordre d'acquisition des lignes, lui, n'est pas séquentiel ni dans la table, ni sur le disque.
Pire, à chaque lecture physique, on acquiert des données dont certaines ne serviront pas car elles concernent une ligne produit déjà traitée ou une ligne produit qui sera traitée beaucoup plus tard.

Bon courage.

[mina24]

Bonjour

essaie les IBO ou FIB+
http://www.ibobjects.com/http://

@+

je pense IBO ou FIB+ ne sont pas gratuit contrairement à Zeos

[cantador]

hé oui,
il n'y a plus grand chose de gratuit et valable en ce domaine..
tu devrais pouvoir télécharger la version d'évaluation des TIBO (ibo5.7.13_2411_Eval.zip)
ces composants doivent coûter environ 300 € TTC (en prenant les options essentielles)
ce qui n'est pas très onéreux pour une entreprise..

@+

[SergioMaster]

Bonjour,

je ne voulais pas m'impliquer dans cette discussion, pour moi il n'y avait pas assez d'éléments concrets, mais la discussion dérivant vers des considérations comme :" en utilisant un autre set de composants", je repars du point de départ ZEOSDBO, Firebird, DBGRid avec une table de environ 400000 lignes et 64 champs.

Tout d'abord, la clause SELECT de la requête, pour une grille il serait étonnant que les 64 champs soit affichés donc tout d'abord :
- éviter d'utiliser un SELECT * FROM mais indiquer les champs qui seront utiles à l'affichage
- Utiliser un TZReadOnlyQuery au lieu d'un TZQuery évitera d'utiliser un double tampon
- La clause ORDER BY augmentera, bien sûr, le temps nécessaire à la récupération des données
Pour ce qui est de FetchRows, une valeur égale au nombre de ligne affichable de la grille suffit amplement , donc 20 est largement suffisant, voir 1 car la récupération de ligne sera égale au nombre de ligne de la grille ! (lire la partie FetchRows de mon tutoriel)
- éviter de récupérer les champs blobs (s'il y en a)

enfin au lieu de faire la recherche par Locate dans l'ensemble de données AMHA il serait bien plus rapide de faire une seconde Requête avec une clause WHERE toutefois, si pour d'autres raisons il fallait en passer par Locate, encadré par un DisableControls et EnableControls améliorera la vitesse

Pour ce qui est de la Primary Key en varchar? bien que cela soit considéré maintenant comme "iconoclaste" AMHA ce n'est pas un facteur de lenteur, si une Primary Key numérique entière avait été mise en lieu et place, il aurait fallu de toute façon ajouter des Index sur le champs servant de Clé de même que sur la colonne Code et la colonne désignation