...et j'avoue aussi que je la comprends pas trop
Il y a deux points à comprendre avec les alias, ce n'est pas «
une table dans la table ».
D'abord, ça facilite la lecture des requêtes surtout lorsqu'elles sont complexes;
Ensuite, lorsqu'on aliase une table, on indique en quelque sorte au SGBD une instance de la table en question. Donc ici, on fait « SELECT * FROM matable ta », MySQL va créer une instance de matable au lieu de piocher directement dans matable. Si on utilise plusieurs fois la même table avec des alias différents, on va avoir des requêtes sur différentes instances. Si tu prends cette même requête et tu tu la fais précéder d'une EXPLAIN, regarde le résultat : les tables indiquées dans le tableau de sortie, ce n'est pas « film » mais chacun des alias.
Donc en résumé, reprenons la requête de
Mazarini :
SELECT A.film
FROM lien A, lien B
WHERE A.film = B.film
AND A.act = a
AND B.act = b
Là, on va lister des films en provenance de l'instance « A » de la table lien, mais on va mettre des conditions :
D'abord une condition de jointure et on va créer une seconde instance de la fable lien qui sera « B »
Ensuite, on met des conditions de tri : il faut que le film trouvé dans A soit le même que dans B, mais que celui trouvé dans A ait pour acteur « a » et celui trouvé dans « B » soit « b ».
Reprend ton graphique un peu plus haut : chacun des cercles est une instance de la même table film.
Et pour ta culture, cette même requête aurait pu être écrite avec une jointure normalisée comme ceci :
SELECT A.film
FROM lien A
INNER JOIN lien B ON A.film = B.film
AND A.act = a
AND B.act = b
On fait une jointure entre deux alias d'une même table ou si tu veux une auto-jointure. Si tu voulais chercher un film où jouent trois acteurs différents, il faudrait ajouter un troisième alias sur la même table et ajuster la condition de jointure, ça donnerait par exemple :
SELECT A.film
FROM lien A
INNER JOIN lien B ON A.film = B.film
AND A.act = a
AND B.act = b
INNER JOIN lien C ON A.film = C.film
AND A.act = a
AND C.act = c
Et ça peut continuer en devenant vraiment beaucoup plus compliqué, d'où l'intérêt de bien réfléchir à la structure d'une base de données avant de se lancer dans le code. Pour ne pas devoir faire ce genre de pirouette, il aurait fallu stocker les acteurs dans une table indépendante et avoir une table relationnelle entre les deux puisqu'un film peut avoir 1 à n acteurs et un acteur peut jouer dans 0 à n films. Mais puisque tu as choisi la forme actuelle, on doit ruser et les alias sont une bonne réponse dans ce cas.
Est-ce que c'est plus clair vu comme ça ?
