Gérer joindre trois tables

Dans le guide de SQL , nous avons vu comment créer des partenariats entre les deux tableaux en utilisant INNER JOIN. Dans cet article nous allons voir comment faire la même chose que la gestion ne dépassant pas deux, mais trois tableaux.

En réalité, c'est une opération très simple qui ne diffère pas d'une jointure de 2 tables communes.
Faisons un exemple: penser à un achat hypothétique d'une simple base de données e-commerce se compose de trois tableaux structurés comme suit:

utilisateurs (utilisé pour la gestion des utilisateurs enregistrés)

• ute_id
• ute_nome
• ute_cognome

produits (utilisé pour le catalogue de produits à la vente)

• prod_id
• prod_nome
• prod_descrizione
• prod_prezzo

achats (utilisé pour enregistrer les achats)

• acq_id
• acq_ute_id
• acq_prod_id
• acq_data

Maintenant disons que vous souhaitez récupérer, à l'aide d'une seule requête, les informations suivantes relatives aux achats effectués par un ID utilisateur donné (par exemple 1), les informations contenues dans trois tableaux distincts: le nom complet de l'utilisateur (table users), nom, description et le prix d'achat du produit (la table Products) et la date d'achat (achats tableau). Comment? Simple ... il suffit d'utiliser une requête comme ceci:

 SELECT



  



 utenti.ute_nome, utenti.ute_cognome,



  



 prodotti.prod_nome, prodotti.prod_descrizione, prodotti.prod_prezzo,



  



 acquisti.acq_data







 FROM utilisateurs







 Achats INNER JOIN







 ON = utenti.ute_id acquisti.acq_ute_id







 INNER JOIN produits







 ON = prodotti.prod_id acquisti.acq_prod_id







 OÙ utenti.ute_id = 1;

 

Comme vous avez sans doute remarqué le commun clause FROM (qui identifie le premier tableau) est suivie par deux INNER JOIN (qui identifient le deuxième et le troisième tableau) accompagné par le lien pertinent sur ​​qui est "un pont" afin de créer un lien rationnelle entre les différents tableaux.

Enfin j'ai juste à vous rappeler que, bien sûr, vous pouvez utiliser la technique vu ci-dessus pour les requêtes plus complexes, impliquant 4, 5 ou plusieurs tables ... en fait, je vous conseille de ne pas exagérer la construction de telles requêtes, bien que théoriquement possible, est souvent laborieuse gérable dans l'application pratique.