Jointures sur tables triées

[pieton57]

Pour l'instant je travaille essentiellement en access mais j'envisage de passer en postgres (ou eventuellement Mysql).

J'utilise des jointures sur de grosses bases de données (plusieurs millions de lignes, 10-15 colonnes).

Les opérations impliquant des jointures sont assez lourdes et la complexité augmente plus ou moins comme le produit des taille des tables jointes.

Les tables que j'utilise étant en général déjà triées sur les variables de jointure.

Les tables "Look up" sont triées et indexées sur les variables de jointure (pas de doublon).

Sans revenir à de la programmation itérative, y aurait il possibilité d'exploiter ces propriétés pour accélérer les opérations:
par des fonctions spécifiques ?
en revoyant la structure de la base ?
autre???

En vous remerciant par avance.

[CinePhil]

Il faudrait que tu donnes la structure de tes tables et les index qui sont placés dessus, ainsi qu'un exemple de requête lente pour qu'on puisse mieux t'aider à optimiser mais dire ceci :

Les opérations impliquant des jointures sont assez lourdes

signifie souvent une mauvaise structure de BDD et/ou un mauvais indexage car les SGBD sont spécialement équipés pour faire des jointures ; c'est leur raison d'être !

[pieton57]

Il s'agit d'une table de gestion de mesures:

Concernant la table principale:

L'indexation est réalisée par:
un lieu: string 3 char (une dizaine de modalités)
un sous lieu: string 2 char (2 modalités communes à tous les lieux)
un sous-sous lieu: string 3 char (3 modalités)
un timestamp à la seconde
suivi d'une dizaine de colonne de mesures short integer

cette base là fait une vingtaine de millions de lignes.

(Les lieux et sous-lieux sont différenciés du lieu principal car ils servent pour certaines aggrégations).

Chaque lieu possède une journée type avec des tranches horaires normales et des tranches horaires sensibles
(une table indexée par lieu/tranche horaire data: indicateur normal/sensible)

Chaque lieu possède un calendrier avec des journées normales et des journées spéciales (index: lieu/date, data: indicateur normal/spécial).

Le but est de faire des moyennes/écart-types etc
Par lieu/sous-lieu/sous-sous-lieu (aggrégé ou non suivant les traitements)
Sur journée spéciale/heure sensible, journée normale/heure sensible, etc...

Au début j'étais parti sur une double jointure. Tables->calendrier->horaires

Puis j'ai aggrégé le calendrier et la table horaire en une table unique ce qui a un peu amélioré les perfs.

Ce qui me dérange c'est que ça reste relativement lourd et qu'a priori on ne tire pas vraiment parti du fait qu'il s'agit pour l'essentiel de base triées (au niveau du timestamp) concaténées.

[CinePhil]

Le problème est peut-être là :

je travaille essentiellement en access

cette base là fait une vingtaine de millions de lignes.

20 millions de lignes sous Access, ça fait beaucoup je trouve. Mais comme je n'ai plus touché à Access depuis pas mal d'années, peut-être que ses capacités ont évolué depuis cette époque.

[pieton57]

Oui c'est probable que ce soit lié aux perf d'access d'autant qu'on utilise encore la version 2000 et que les machines que je peux avoir sont assez pourraves. Pour l'instant on découpe les bases et on les traite par morceaux car Access est limité à des bases de 2Go.

Nous avions essayé de tout passer en mysql mais les résultat étaient assez mitigé car bécanes pas terrible (Athlon 64, 1Go de Ram sous XP...)

Nous sommes en train de négocier pour récupérer du matos plus correct.

Par contre sur la modélisation y-a-pas de problème apparent?

[SQLpro]

Accès est un système de fichiers et ne sait pas travailler en RAM. En revanche tous les serveurs SQL (SQL Server, PostGreSQL...) travaillent exclusivement en RAM. Dès lors les performances seront sans commune mesure avec ce que vous avez sous Access !

A +

[CinePhil]

Envoyé par pieton57

Par contre sur la modélisation y-a-pas de problème apparent?

Il faudrait que tu montres ici le schéma de ta BDD pour qu'on puisse te donner notre avis. Ta description un peu plus n'est pas très claire.