Discussion :

[fdraven]

Bonjour,

Je travaille actuellement sur une application ACCESS qui comporte des tables assez conséquentes en terme de nombre d'enregistrements ( + 400 000 ). Je dois effectuer des traitements sur ces tables pour élaborer divers statistiques et je cherche des conseils pour optimiser le temps de ces requêtes.

- Est-ce qu'une requête d'insertion ou d'update est plus rapide lorsqu'elle comporte une sous requête dont le critère de recherche est indexé ?
- Vaut-il mieux utiliser le terme EXISTS ou IN en terme de rapidité de recherche ?
- Quelles sont les solutions pour contourner les sous requêtes ? Si oui est-ce vraiment plus rapide en terme de temps ?


Merci d'avance de toutes vos réponses.

[fdraven]

Personne d'inspiré par des questions de performance
J'uppe le sujet au cas où une gentille personne voyant de la lumière arrive à apporter un début de réponse.

[Neilos]

Salut,

je cherche moi aussi à optimiser les performances mais sur des tables beaucoup plus petites.

Je me demande aussi pour les sous-requête. Une méthode est de faire une jointure (ça peut remplacer le EXISTS si tu n'as pas de critères dessus)...je suis toujours à la recherche de solution.

[random]

une des solutions est une horreur conceptuelle (à priori) c'est la table à plat(abandon du modèle relationnel et toutes les données dans la même table)

cela donne avec une indexation judicieuse et un tri poussé lors de l'écriture des perfomances remarquables

on crée une base contenant la table à plat pour des calculs importants
et des traitements compliqués puis on rapatrie les données retraitées

[fdraven]

Qu'appelles-tu une indexation judicieuse ?

[cafeine]

une des solutions est une horreur conceptuelle (à priori) c'est la table à plat(abandon du modèle relationnel et toutes les données dans la même table)

cela donne avec une indexation judicieuse et un tri poussé lors de l'écriture des perfomances remarquables

on crée une base contenant la table à plat pour des calculs importants
et des traitements compliqués puis on rapatrie les données retraitées

Random a raison dans certains cas, la création d'une ou plusieurs tables temporaires "à plat" et des indexations permettent de gagner du temps.

[fdraven]

Est-ce qu'Access gère vraiment bien les index ? (surtout ceux qui sont autres que clé primaire ) .

[random]

oui access gère bien les index
et même très bien

[random]

Qu'appelles-tu une indexation judicieuse ?

je nomme indexation judicieuse index sur tous les champs utilisés pour les tris

plus indexation combinée pour les champs utilisés en association

[fdraven]

Je viens de lire dans un des tutoriels de ce forum qu' un EXISTS est plus rapide en terme de performance qu' IN. Quelqu'un en connait-il la raison ?

[fdraven]

Nouvelle question:

1) ex : insert into table1 Select ... Where Exists ( select * From table2 Where table2.champ1 = table1.champ1 And table2.champ2 = table1.champ2...);

Vaut-il mieux créer un index sur chaque partie du champs de la sous requête ou créer 2 index ( regroupant champ1 et champé) ? pour obtenir des meilleurs performances au niveau du temps d'exécution de la requête.

2) Quelle est la différence entre un index CLUSTERED et un index NONCLUSTERED ?

En espérant que quelqu'un est un début de réponse. Merci d'avance

[random]

Nouvelle question:


2) Quelle est la différence entre un index CLUSTERED et un index NONCLUSTERED ?

un index non clustérisé est comme un annuaire je cherche Dupont
son adresse est 27 rue de la grange aux loups à nantes où je me rends et ainsi de suite pour dupont 122 rue de Siam Brest (j'ai évité paris brest pour des questions de tour de taille)

avec un index clustérisé dupont va habiter avec tous les dupo..... rue de la grange aux loups , j'irais donc du 27 au 122

remplace les adresses par des clusters(portion contigue) de disque dur et imagine le gain de temps