Bonjour,
je debute un peu en SQL et je me pose une question sur la difference entre c'est 2 commandes.
 
Supposons que j'ai une table "comments" qui contient les champs : id, name, user_id
et une table "users" qui contient : id, name, grade
 
SELECT "comments".*  
FROM "comments" INNER JOIN "users" ON "users".id = "comments".user_id
WHERE "users".grade = 'admin'
 
SELECT "comments".*  
FROM "comments"
WHERE "comments".user_id IN (SELECT id
                                          FROM users
                                          WHERE "users".grade = 'admin');
 
En fait, je me demande si le fait de faire une jointure ne charge pas inutilement des champs (dans le cas ou la table "users" contiendrais d'autre champs) mais je me demande aussi si le fait de faire une requete imbriqué n'est pas une perte de temps.
Merci.

C'est strictement équivalent d'après moi au niveau du résultat.
Après la deuxième solution est très brouillon et nécessite de faire 2 requètes en réalité...
C'est aussi une question de norme.
Quand tu gereras des requètes un peu plus complexes, tu utiliseras les jointures, car c'est plus propre, plus lisible, plus éditable, etc...
 
Compare les deux méthodes si tu as une dizaine de tables à joindre.
Dans la première méthode, tu as 10 lignes de INNER JOIN.
Dans la seconde, c'est 10 requètes imbriquées. Immonde !

Merci

Oui, la première requête est beaucoup plus propre

Ce n'est pas qu'une question de lisibilité et de "propreté". Dans ce cas là, il est également surtout question de performances.
 
Dans le cas de la deuxième requête : le SGBD va d'abord exécuter la sous-requête. Puis la première requête. Puis, pour chaque enregistrement de ta table "comments", il va tester si l'user.id se trouve dans le jeu d'enregistrement de la table user.
 
Alors qu'avec la première requête, le SGBD contient des index qui lui permettent de trouver très rapidement les données que tu lui demande, en une seule requête, sans avoir d'autres tests à effectuer que le user.grades="admin". Ce sera beaucoup plus rapide, et ça va même permettre au SGBD de tenir des statistiques qui serviront plus tard à optimiser encore mieux son temps de travail pour des requêtes équivalentes.

Le plan d'exécution est identique avec les deux requêtes.
Testé à l'instant, par contre je ne sais pas si c'est pas un optimiseur quelconque qui est venu fourrer son nez là-dedans au moment de l'exécution.

Avec quel SGBD ?
 
Je pense qu'un optimiseur est venu s'occuper de ça effectivement.
Pour une requête simple comme celle-ci, c'est effectivement pas un problème. Mais dans le cas général, il vaut mieux faut à tout prix éviter les "IN (SELECT ...)", surtout si c'est juste pour faire une jointure.
 

Sybase 15 dans mon cas.

Sous SQL Server 2005, c'est également le même plan d'exécution.
 
N'empêche que c'est pas une habitude à avoir que d'utiliser des "IN (SELECT ..."
Et je suis sûr qu'avec un poil de complexité en plus, on peut tout faire péter le serveur ²