Comment éviter les jointure sur plusieurs tables [Résolu]

[xavier81]

Bonjour;

je suis amené à alimenter une table mais pour ce faire j'ai besoin de faire des jointures sur 7 ou 8 tables pour récupérer tous les champs dont j'ai besoin.
et je sais qu'en termes d'optimisation ce n'est pas fameux surtout quand on a des tables volumineuses.

y a-t-il une solution pour contourner ça ?

merci d'avance.

[Lharuun]

Bonjour,

Si tu veux éviter les jointures, tu peux intégrer les informations directement dans la table centrale, c'est pas forcément plus mieux.

- Tu fais péter la volumétrie de ta base.
- Tu as des informations en double de tous côtés.
- Si tu dois modifier un attribut externe d'une liaison, plutôt que faire
un update sur un enregistrement de la table étrangère tu vas peut être
devoir faire cet update sur des milliers d'enregistrements.

D'un autre coté, 8 tables ne me parait pas exagéré quand je vois certaines requêtes que j'ai été amené à écrire tout en gardant de très bonnes performances.

Après, il est important de savoir comment travaille le SGBD sur lequel tu bosses.
Ça devient un question d'optimisation.

Il m'est arrivé de faire certaines requêtes qui mettaient plusieurs minutes à s'exécuter, puis à force d'optimisations tomber en dessous de la seconde.

Je ne sais pas avec quel SGBD tu travailles, mais tu dois surement avoir des instructions d'analyse d'exécution de requête.

Cordialement.

[CinePhil]

Il ne faut pas avoir peur des jointures, c'est l'opération la plus optimisée dans un SGBDR.
Du moment que la BDD est correctement modélisée, les types de colonnes judicieusement choisis et les tables correctement indexées, toute requête, même sur des millions de lignes, doit se faire en moins d'une seconde sur un serveur correctement dimensionné.

surtout quand on a des tables volumineuses

Combien de lignes par table ?

[xavier81]

bonjour;


mon SGBD est SQLserver et le nombre de lignes dans les tables varie entre un million et 3 millions lignes.

[CinePhil]

C'est pas mal mais pas extraordinaire.
SQL Server est tout à fait capable de soutenir cette charge.
Reste le dimensionnement du matériel (ne pas être avare de mémoire vive), la modélisation de la BDD (normaliser au maximum avant de songer à toute dénormalisation), le choix des types de colonnes (clefs primaires et étrangères entières ou à la riguer en CHAR < 4 notamment), l'indexation des tables.