Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1370 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [Access] Différence de vitesse INNER JOIN et 2 requetes imbriquées?

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[Access] Différence de vitesse INNER JOIN et 2 requetes imbriquées?

n°1483660
bab
Posté le 29-11-2006 à 12:13:03  profilanswer
 

J'imagine que la question a été abordées souvent mais apres quelques recherches sur le forum, je ne trouve pas vraiment la réponse.
 
Est-ce qu'il y a vraiment une différence de vitesse entre un INNER JOIN et 2 requetes imbriquées l'une dans l'autre ?
Exemple :
 
Select t1.champ1,t1.champ2,t2.champ5 from t1 inner join t2 on t1.champ6=t2.champ6
=> exploitation de champ5
 
et  
 
req1 = Select champ1,champ2 from t1
req2 = Select champ5 from t2 where champ6=req1(champ6)
=> exploitation de champ5
 
Ne faites pas attention à la syntaxe bien sur, j'ai simplifié pour l'exemple.

mood
Publicité
Posté le 29-11-2006 à 12:13:03  profilanswer
 

n°1483665
ZeBix
edit > preview
Posté le 29-11-2006 à 12:20:50  profilanswer
 

Clairement oui il y a une différence, même si pour un exemple simplifié elle est quasi imperceptible.
 
Multiplier les requêtes à ton moteur SQL, c'est plus lent que d'envoyer une seule requête, surtout si celle-ci comporte des liaisons entre des tables via des champs indexés ...
 
Si tu travailles en PHP, si on fait 2 requêtes, ça signifie :
- envoyer la requête
- le serveur la traite et renvoie un record set
- tu fetch dans le record set et retires le champ qu'il te faut
- tu envoies la deuxième requête avec comme paramètre le champ retiré de la première
- le serveur traite et renvoie le record set
- tu fetch les champs voulus.
 
vs.
 
- tu envoies la requête
- le serveur la traite (et MySQL c'est rapide hehe surtout en indexé) et te renvoie le record set
- tu fetch ce qu'il te faut.
 

n°1483703
bab
Posté le 29-11-2006 à 13:50:16  profilanswer
 

ok et dans le cas de Access, est-ce que ça change quelque chose ? car dans ce cas là il n'y a pas de moteur "serveur", c'est l'application qui traite tous les échanges.
 
une autre question : est-ce qu'indexer plusieurs champs dans une table prend plus de place dans la base ou est-ce que ça ne change ? et dans ce cas j'imagine que plus il y a de champs indexés, moins il y a d'interet à la chose ?

n°1483737
FlorentG
Unité de Masse
Posté le 29-11-2006 à 14:14:15  profilanswer
 

Oui, indexer prend plus de place. Mais bon, c'est pas trop grave, le tout c'est d'indexer les champs les plus stratégiques


---------------
last.fmflickr
n°1483875
ZeBix
edit > preview
Posté le 29-11-2006 à 17:30:29  profilanswer
 

@bab : Dans le cas d'Access en local la différence devrait être imperceptible ... mais considère toujours qu'une requête c'est mieux que 2. Et puis ce sont de bonnes habitudes à prendre :)
 
Pour continuer ce que FlorentG conseille, "stratégique" ici veut dire que tu dois indexer les clefs (quoique normalement ce soit fait automatiquement sur tous les SGBD courants maintenant - à confirmer), ainsi que les champs auxquels tu vas accéder "par l'extérieur" :  
 
Par exemple tu as une requête du genre  

Code :
  1. Select table1.champ,table2.champ from table1
  2. inner join table2 on table1.ID = table2.ChampPasID


 
En supposant que la clef primaire de table2 soit "ID", tu as tout intérêt à indexer "ChampPasID", surtout s'il est susceptible d'être par exemple linké de la sorte à plusieurs reprises.
 

n°1484763
bab
Posté le 01-12-2006 à 09:44:44  profilanswer
 

oki, je vais faire comme ça alors.
 
ce qui est dommage c'est qu'on a aucune idée de l'impacte au niveau de la vitesse quand on fait des indexations.
c'est pas forcément évident de savoir si on a fait des modifs efficaces.

n°1484782
ZeBix
edit > preview
Posté le 01-12-2006 à 10:06:38  profilanswer
 

L'impact au niveau de la vitesse dépendra d'un tas de facteurs qu'il est impossible de théoriser : le contenu de ta table, sa grosseur, les requêtes que tu effectues, etc. Le plus facile est que tu t'en rendes compte toi-même, en essayant avec et sans index.
 
Il y a quelque temps j'ai bossé sur des bases de données MySQL, et j'avais de grosses requêtes bien lourdes qui devaient aller chercher des clefs externes dans des tables de 800000 enregistrements ... non indexées ... (j'avais pas bâti les tables moi-même). Je me demandais pourquoi c'était si lent (car à mon sens il était logique qu'elles fussent déjà indexées...) et me suis rendu compte ... après avoir déterminé les index mes requêtes prenaient en moyenne 1/4 du temps qu'elles prenaient avant.


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  [Access] Différence de vitesse INNER JOIN et 2 requetes imbriquées?

 

Sujets relatifs
[VB Access]Supprimer un élément d'un textboxProblème de connexion a une base de donnée VBA Access
différence entre fonction et méthodeDifférence entre les HashSet et les LinkedHashSet dans l'API Java
Défi pour les pros : importer des données excel vers access...Plusieurs requêtes provenant du même client (sql server)
Aide accessACCESS : plusieurs requêtes en une...
[PHP] difference d'accès a un site par rapport au model 
Plus de sujets relatifs à : [Access] Différence de vitesse INNER JOIN et 2 requetes imbriquées?


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR