Discussion :

[isma92]

bonjour a tous,

j'aimerais avoir des avis concernant le problème auquel je suis confronté en stage :

il existe une table "achats" , dans la bdd de l'entreprise qui contient des millions de lignes. On m a demandé de trouver une solution réduire le temps de recherche dans cette table. j ai pensé a 2 solutions (mais de nouvelles sont les bienvenues) :

- j'exporte tous les ans la bdd dans un fichier et a la suite d'une recherche je recharge le fichier concernant la période désirée pour la recherche (les recherches concernent principalement l'année en cours, donc il y a rarement des recharges) ->inconvénient : le temps de recharge du/des fichiers peut rendre la recherche fastidieuse.

- je créée une table "achats" par exercice. par exemple achats2008, achats2009. inconvenient->solution qui demande plus de place, meme si la capacité de stockage n'est pas un probleme pour moi.

voila. n'hesitez pas me communiquer d'autres idées ou a corriger mes erreurs de raisonement

merci

ps : il s agit d une bdd postgres

[scheu]

Création d'indexes ou partitionnement (héritage de tables)
Avec en tous les cas un calcul régulier des stats de la table

[VASAPANCH]

Effectivement je pense que la première chose à faire (au niveau conception) est de poser des indexes sur les champs de ta table sur lesquels ton application de recherche permet d'opérer. A priori ces champs sont sûrement : date, année, etc...

Dans le cas de champs liés à d'autres tables (par exemple un champ id_client lié à une table client) il est alors préférable de poser une foreign key (qui garantit l'intégrité référentielle) mais permet aussi un gain de temps. Si tu cherches tous les achats passé par "Un tel" (dont tu ne connais pas directement l'ID) alors ta requête risque d'être sensiblement plus rapide (du moins je le crois).

Enfin, au niveau administration de ta base il faut bien sûr lancer des vacuums régulier sur cette table 'critique' et pourquoi pas d'autres analyses.

Je ne suis vraiment pas expert et je te conseilles d'attendre d'autres avis qui pourront conforter ou infirmer ma position.

En tout cas voilà un début... espèrons que d'autres contribuent car la réponse d'experts à ta question intéresse sûrement beaucoup de monde dont je suis...

Cordialement,

[isma92]

merci pour vos réponses. en fait la table possèdes deja des indexes.
la solution du partitionnement de la table par exercice me parait pertinente. je ne connaissait pas cette solution, elle m evitera de crééer une table par exercice...je vais creuser dans cette voie

merki

[scheu]

Tu as toutes les infos sur le partitionnement dans la doc officielle (selon ta version de base)
De plus , faire régulièrement un VACUUM FULL de la table

[isma92]

rectification: après documentation sa m obligera bien a créer une table par exercices, mais sa reste une bonne solution

[scheu]

rectification: après documentation sa m obligera bien a créer une table par exercices, mais sa reste une bonne solution

Oui, sauf que c'est en utilisant l'héritage que l'optimiseur postgresql pourra choisir les tables (les partitions) à lireelon la requête, sans devoir parcourir la totalité des données