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.

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.
 

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 ?

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

@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  

 
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.
 

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.

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.