Discussion :

[chekkal]

Bonjour à tous,

Je voudrais savoir s'il ya un moyen pour accélerer la recherche dans une base de données volumineuse (+500 000 enregistrements) .

Dans mon cas j'ai une application pour supperette et avec le volume de Travail (environ 3000 clients par jour * par le nbre d'article ) et à chaque mise à jour de la base de données il faut recalculer le total particulier et general.

Aussi je sais pas combien firebird peut supporter d'opérations par connection.

merci de me repondre.

[SergioMaster]

Bonjour,

à chaque mise à jour de la base de données il faut recalculer le total particulier et general.

je présume que c'est une sorte de tableau de bord parce que sinon je vois pas vraiment . il faudrait a minima une description des tables

[TryExceptEnd]

Bonjour à tous,

Je voudrais savoir s'il ya un moyen pour accélerer la recherche dans une base de données volumineuse (+500 000 enregistrements) .

ce n'est surement pas le nombre d'articles mais celui de tickets après une période données, ce qui ne doit pas poser problème si on gère bien ses requêtes.

Dans mon cas j'ai une application pour supperette et avec le volume de Travail (environ 3000 clients par jour * par le nbre d'article ) et à chaque mise à jour de la base de données il faut recalculer le total particulier et general.

Une seule Procédure Stocké peut tout faire et tu ne rafraichi que le ticket en cours de calcul.

Aussi je sais pas combien firebird peut supporter d'opérations par connection.

Firebird peut très bien supporter cette charge.

[chekkal]

j'ai une Base de données
SAISIE.FDB qui contient les tables:

1- VEN (ventes)
2- ACH (achat)

j'ai la fiche delphi fiche8 pour saisir des données dans un DBGRID bien sur

et chaque mise à jour sur la table VEN je recalcul le total partiel(ticket)
'select sum(mon) as mon from VEN where (tic='+var1+')'
et le total general
'select sum(mon) as mon from VEN'
et avec le temps ça devient vraiment long.

[SergioMaster]

Bon , alors plusieurs remarques

a) la partie delphi

j'ai la fiche delphi fiche8 pour saisir des données dans un DBGRID bien sur

ben non pas aussi sur que ça , généralement je n'utilise les DBGrid que pour des lectures , pas pour des saisies

exemple : image programme ventes chaussures (non finalisé , projet abandonné) en PJ

Code :

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

select sum(mon) as mon from VEN where (tic='+var1+')'

sur ce code SQL déjà , pas besoin des parenthèses
ensuite il vaux mieux faire une requête paramètrée
[CODE=SQL]SELECT SUM(mon) FROM VEN WHERE tic=:v[code]
c'est certainement pas celle là qui va prendre du temps
par contre pour le total général

Code :

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

select sum(mon) as mon from VEN

là évidemment dans 4 ou 5 ans ça risque de faire pas mal à lire
suggestion : une table TABLEAU_BORD par exemple
TABLE TABLEAU_BORD
(DATE_JOUR DATE,
MONTANT_TOTAL NUMERIC(15,2));

et des Triggers AFTER INSERT , AFTER UPDATE , AFTER DELETE sur la Table VEN

[chekkal]

alors comme tu fait pour recevoir et saisir des données

exemple: j'ai une application de facturation et quant l'utilisateur saisie des données sur une facture données sur plusieurs ligne.

1er ligne :achat boissons
2eme ligne:achat olive
ect.
et la solution de saisir dans Tedit (par exemple) n'est pas interessante,
parceque ca perturbe l'utilisateur et il sait plus à qu'elle ligne il est arrivé et ça crée du retard dans l'execution

[SergioMaster]

Tout d'abord , la Base est peut être à revoir

j'ai une application de facturation et quant l'utilisateur saisie des données sur une facture données sur plusieurs ligne.

1er ligne :achat boissons
2eme ligne:achat olive

déjà j'ai 2 tables pour la facturette
1 - ENTETE de facture
2 - LIGNE de facture
dans ton exemple cela donnerai
ENTETE : FACTURE 1
LIGNE : FACTURE 1, LIGNE 1 BOISSONS
FACTURE 1, LIGNE 2 OLIVES

sur l'image que j'ai fourni les lignes sont transmises dans un blob à l'image du ticket qui va sortir (cela pourrait être une DBGrid en lecture seule) mais la saisie est faite pour une ligne à la fois
via des TDBEdit ou TDBxxxx

[chekkal]

je te l'avait dit.

tu utilise des composants pour la lecture des saisie des données et d'autres pour la lecture . pour l'utlisateur de l'application je crois ça deviendera et en plus tu doit gerer tous ces composants

vraiment je trouve pas ce qui rend BDE obselête.

[SergioMaster]

Si tu estimes que mes 15ans d'expérience Delphi et mes 35ans+ de carrière ne font pas le poids face a tes convictions (sans parler de tous les autres posts/articles parlant du BDE) rien ne t'empêche de continuer .

pour l'utilisateur de l'application

l'utilisateur se moque complètement des composants que tu as a gérer , pour lui seul compte l'interface

[chekkal]

total respect , je ne doute nullement de ton expérience et merci pour tes réponses.

en ce qui me concerne, j'ai pas une grande expérience, mais je t'expose des fait réels c'est tout.

mais ce que j'essaye de comprendre c'est quoi les limites de BDE par rapport à ce que je cherche

tu ma parler des fichier temporaire dans firebird, ces fichiers temporaires doivent être créer à l'intérieur de la base de données? est-ce que on peut modifier les champs de ces tables automatique par programmation.

les fichiers temporaire que je crée automatiquement avec BDE sans creer pas en réseau mais seulement sur le poste utilisateur et il à aucune relation avec les autres poste.

[SergioMaster]

Je l'ai déjà dit , oublie le BDE , tu as d'autres alternatives tout aussi efficaces comme les Tmemtables par exemple .
Je t'ai parlé de tables temporaires et bien évidemment on peut modifier/créer etc... des enregistrements dans ces tables ! Must une seule table suffit pour plusieurs utilisateurs , un utilisateur ne verra que ses enregistrements .

Néanmoins je trouve que l'on dérive de plus en plus du sujet principal à savoir

Je voudrais savoir s'il y a un moyen pour accélerer la recherche dans une base de données volumineuse

Lors ma réponse est la suivante : je pense que ta structure de BDD est incorrecte surtout s'il n'y a que deux tables . Une accélération se fait via les Index en général . Donc si , "enfin", on avait la structure de la base (DDL) on y verrait peut être plus clair .

Ton

à chaque mise à jour de la base de données il faut recalculer le total particulier et général.

n'a jamais été très clair pour moi que signifie Total particulier , total d'une ligne d'un ticket ? total d'un ticket ? ....
quant à total général : total du ticket , total de la journée , total du mois ....

[chekkal]

pour le total général je le fait pour une seule année seulement:

je m'explique:
j'ai une base de données BASE: saisie.fdb qui contient 2 table (ACH et VEN)
et pour chaque année je crée une base de données semblable a saisie.fdb
formater comme suite :S0012013.fdb (001:numéro de dossier/ 2013:exercice)

en fait, je fait pas le cumul des données erreur que j'ai déjà payé cher avec BDE, pensez à une table avec 1 000 000 d'enregistrement

et chaque nouvelle année je créer automatiquement une table solde stock précédent.

jusqu’au là tout va bien. La ou ça pose problème c'est dans la cas d'une table PRO avec 20 0000 articles le calcul des stocks doit passer par tout ces articles sachant que la table PRO se trouve sur une autre base données dossier.fdb.
voici la procédure stockée que j'utilise:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
declare dat2 date;
   declare pro2 varchar(20);
   declare pua2 numeric(14,5);
 
declare qte2 numeric(14,5);
 
declare i integer;
 
BEGIN
 
        DELETE FROM STK; 
 
   for select pro,sum(qte) as qte from ACH where (fac='00000')and(pro is not null)and(dat>=:datd)and(dat<=:data) group by pro into :pro,:qte do
 
   begin
            INSERT into STK (dat,pro,pua,qto) values(CAST(:dat1 as date),:pro,0,:qte);
 
            suspend;
   end 
 
   for select pro,sum(qte) as qte from ACH where (fac<>'00000')and(pro is not null)and(dat>=:datd)and(dat<=:data) group by pro into :pro,:qte do
 
   begin
 
         IF (EXISTS(SELECT pro FROM STK WHERE pro=:pro))
 then
             UPDATE STK set qta=:qte where (pro=:pro);
        else INSERT INTO STK (dat,pro,pua,qta) values(CAST(:dat1 as date),:pro,0,:qte);
 
        suspend;
         end
 
        for select PRO,sum(qte) from VEN where (PRO is not null)and(dat>=:datd)and(dat<=:data) group by pro into :PRO,:qte do
 
        begin 
 
              IF (EXISTS(SELECT pro FROM STK WHERE pro=:pro))
 then
                   UPDATE STK set qtv=:qte where (pro=:pro);
 
              else INSERT INTO STK (dat,pro,pua,qtv) values(CAST(:dat1 as date),:pro,0,:qte);
 
              suspend;
 
        end
 
END

[SergioMaster]

achant que la table PRO se trouve sur une autre base données dossier.fdb.

grosse erreur à mon avis , personnellement je garderai les 'mouvements de l'année' dans la même base, et archiverai ceux ci en fin d'année (soit l'inverse de ce qui est fait)

Ensuite , je pense qu'il y a une erreur de transcription car les 2 premiers SELECT sont sur ACH et donc me semblent identiques !!

un essai de simplification

Code :

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

1
2
3
4
5
6
7
8
 
FOR SELECT pro,sum(qte) AS qte FROM ACH WHERE (fac='00000')AND(pro IS NOT NULL)AND(dat>=:datd)AND(dat<=:DATA) GROUP BY pro INTO :pro,:qte do
 
   begin
            INSERT INTO STK (dat,pro,pua,qto) VALUES(CAST(:dat1 AS date),:pro,0,:qte);
 
            suspend;  // inutile
   end

ceci devrait faire la même chose

Code :

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

1
2
 
INSERT INTO STK(dat,pro,pua,qto) SELECT CAST(:dat1 AS date),Pro,0,SUM(QTE) FROM ACH WHERE (fac='00000') AND(pro IS NOT NULL)AND(dat BETWEEN :datd AND DATA) GROUP BY 1,2,3

en utilisant une astuce : une Common Table Expression on doit pouvoir faire tout en un seul Insert . En supposant que les quantités sont des entiers

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
WITH C AS 
(SELECT pro,sum(qte) AS qte,0 as qta,0 as qtv FROM ACH WHERE (fac='00000') AND (pro IS NOT NULL) AND (dat BETWEEN :datd AND :DATA) 
UNION
SELECT pro,0,sum(qte) AS qta,0 FROM ACH WHERE (fac='00000') AND (pro IS NOT NULL) AND (dat BETWEEN :datd AND :DATA) 
UNION
SELECT pro,0,0,sum(qte) AS qtv FROM VEN WHERE (fac='00000') AND (pro IS NOT NULL) AND (dat BETWEEN :datd AND :DATA) 
)
 
INSERT  INTO STK (dat,pro,pua,qto,qta,qtv)
SELECT CAST(:dat1 AS date),pro,0.00,sum(qte),sum(qta),sum(qtv)
group by 1,2,3

[chekkal]

j'utilise pour chaque année un exemplaire de base de données pour éviter le cumul des données au cours des années. a mon avis ça affecterais les traitements et les calcul sur la base.

franchement j'ai pas compris ton code si tu peut m'expliquer son fonctionnement , j'ai utilisé 2 select pour ACH parce-que le premier affecte le champ "QTO" et l'autre select "QTA" et le 3eme select sur la table ven affecte le champ "QTV". j'ai noté aussi inutile pour la commande "suspend" pour être honnête je l'ai utilisé par défaut parce-que il me signale une erreur à chaque fois que je l’enlève. noté aussi que dat1 est une variable et pas un champ.

[SergioMaster]

j'utilise pour chaque année un exemplaire de base de données pour éviter le cumul des données au cours des années. a mon avis ça affecterais les traitements et les calcul sur la base.

no comment , je persiste a croire que la structure de la BDD est "farfelue" , j'ai moi aussi une appli avec des milliers de références et n'ai aucun problème

franchement j'ai pas compris ton code si tu peut m'expliquer son fonctionnement , j'ai utilisé 2 select pour ACH parce-que le premier affecte le champ "QTO" et l'autre select "QTA" et le 3eme select sur la table ven affecte le champ "QTV".

deux select pour une même valeur voilà qui fait un traitement de trop

pour comprendre mon code , il suffit de comprendre les CTE, pour le INSERT INTO .... SELECT c'est du B.A.B.A. voir la Syntaxe de INSERT

Qu'est ce qu'une CTE , en simplifiant énormément c'est une 'sous-requête' permettant de mâcher le travail par la suite . Ce que j'ai fait , après avoir lu que les structures étaient identiques c'est simplement fait une union de toutes les sélections en décalant la valeur de sum(qte)

a ma grande honte je me rend compte qu'il manque une ligne à mon code final

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
WITH C AS 
(SELECT pro,sum(qte) AS qte,0 AS qta,0 AS qtv FROM ACH WHERE (fac='00000') AND (pro IS NOT NULL) AND (dat BETWEEN :datd AND :DATA) 
UNION
SELECT pro,0,sum(qte) AS qta,0 FROM ACH WHERE (fac='00000') AND (pro IS NOT NULL) AND (dat BETWEEN :datd AND :DATA) 
UNION
SELECT pro,0,0,sum(qte) AS qtv FROM VEN WHERE (fac='00000') AND (pro IS NOT NULL) AND (dat BETWEEN :datd AND :DATA) 
)
 
INSERT  INTO STK (dat,pro,pua,qto,qta,qtv)
SELECT CAST(:dat1 AS date),pro,0.00,sum(qte),sum(qta),sum(qtv)
FROM C  //<<<< le manque
GROUP BY 1,2,3

PS. j'avais bien compris que dat1 est une variable et c'est bien ainsi que je l'ai traité

[chekkal]

je me permet de persister, a ma connaissance une base de données et comme l'ordinateur il s'use avec le temps (Nbre opération*nbre année) non?
Ensuite, à ma connaissance à chaque fois qu'une requête sql est émise sur la base de données le calcul doit chercher sur toutes les données de la table et globalement les requêtes ce font que pour une période annuelle (la même année).

a propos il sert à quoi le suspend

[SergioMaster]

je me permet de persister, a ma connaissance une base de données et comme l'ordinateur il s'use avec le temps (Nbre opération*nbre année) non?

il m'étonnerait que l'entreprise veuille garder tous les mouvements sur x années,la mienne par exemple ne garde que sur 6 mois . Ensuite , comme expliqué ces mouvements sont basculés dans une base d'archive . Il est vrai qu'une BDD grossit avec le temps (surtout si les transactions sont mal gérées et qu'aucune maintenance n'est faite) mais une SGBD Firebird peut avoir plusieurs Gigas (voire Teras) avant d'être 'fatiguées' .
Non , à mon avis votre analyse des Données et donc la structure de la SGBD pêche d'analyse , vous êtes restés trop 'fichiers' certainement par bonne connaissance de Paradox ou équivalent mais pas assez d'un SGBD relationnel . un bon MCD (merise/ ou équivalent via d'autres méthodes) est la clé du succès . Une bonne indexation (je ne parle pas de clé primaire) par dessus et les résultats seront très honorables

Ensuite, à ma connaissance à chaque fois qu'une requête sql est émise sur la base de données le calcul doit chercher sur toutes les données de la table et globalement les requêtes ce font que pour une période annuelle (la même année).

pas s'il y a un index sur l'année

a propos il sert à quoi le suspend

généralement c'est dans le cas d'une procédure qui renvoi des données , le suspend envoi les données (explication simplifiée)

[chekkal]

je crois que nous procédons de la même manière moi et toi.

tu archive chaque 6 mois dans une base de données archives

moi, je crée une base de données pour chaque année avec la possibilité de revenir à l'année précédente à tout moment. en effet j'ai un Tedit qui reçoit l'année et on le changeant la système se met automatiquement sur la base de données de cette année là.

mais comme tu l'a déjà dit je crois q' ont sort du sujet.

ma procedure calcul les stocks existants en prenant (le totaux des achat groupé par produit - les totaux des ventes groupé par produit), j'usqua là tout marche bien (vite).

mais moi j'ai besoin de récupérer les designations des produits qui se trouve sur autre base de données, j'ai utilisé ce code:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
   FOR EXECUTE STATEMENT 'select NUM,PRO,PUA,DES from PRO' ON EXTERNAL DATA SOURCE :che AS USER 'sysdba' PASSWORD 'masterkey'
         INTO :num,:pro,:pua,:des DO
         begin
               if (:num=:num1) then
               begin
                     UPDATE STK set PUA=:PUA,DES=:DES,QTR=QTO+QTA-QTV  where (pro=:pro);              
                     UPDATE STK set MON=PUA*QTR  where (pro=:pro)and(pua is not null)and(qtr is not null);                                       
               end  
        end

l'a le système doit passer par tout les produit 15 000 environs pour récupérer les désignations

noté bien que "che" est un paramètre de la procédure qui reçoit le chemin à la base de données

[SergioMaster]

je crois que nous procédons de la même manière moi et toi.

en tout cas on a pas la même conception

tu archive chaque 6 mois dans une base de données archives

non, j'archive les mouvements qui ont plus de 6 mois (pas tous les 6 mois) et ce dans une seule base de données ARCHIVE

moi, je crée une base de données pour chaque année avec la possibilité de revenir à l'année précédente à tout moment. en effet j'ai un Tedit qui reçoit l'année et on le changeant la système se met automatiquement sur la base de données de cette année là.

Comme les accès sont relativement peu fréquent sur les archives (1 fois tous les 6 mois a peu près et par un seul user ...

note : pour les SQL merci d'utiliser les balises Code (sélectionner le texte et cliquer sur le bouton # ou saisir manuellement les balises)

mais moi j'ai besoin de récupérer les designations des produits qui se trouve sur autre base de données

Avec FB 2.1 et < le ON EXTERNAL DATA SOURCE n'existait pas donc ...

Code :

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

1
2
3
 
UPDATE STK set PUA=:PUA,DES=:DES,QTR=QTO+QTA-QTV where (pro=:pro);
UPDATE STK set MON=PUA*QTR where (pro=:pro)and(pua is not null)and(qtr is not null);

2 erreurs a mon avis
- QTR est une valeur devrait être une valeur computed
- MON est une valeur devrait être une valeur computed

Code :

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

1
2
QTR INTEGER COMPUTED BY COALESCE(QTO,0)+COALESCE(QTA,0)-COALESCE(QTV,0);
MON NUMERIC(15,2) COMPUTED BY COALESCE(PUA,0)*QTR;

et ainsi pas besoin de faire de Update sur ces champs

[chekkal]

j'ai voulu rattraper mon retard alors j'ai pris le dernier firebird 2.5

et "on external" marche bien, mais c'est ça lenteur qui me pose problème