Votre guide ultime des jointures SQL :OUTER JOIN – Partie 2

La jointure externe est au centre de la scène aujourd'hui. Et ceci est la partie 2 de votre guide ultime sur les jointures SQL. Si vous avez manqué la partie 1, voici le lien.

À première vue, l'extérieur est le contraire de l'intérieur. Cependant, si vous considérez la jointure externe de cette façon, vous serez confus. Pour couronner le tout, vous n'êtes pas obligé d'inclure le mot outer explicitement dans votre syntaxe. C'est facultatif !

Mais avant de plonger, parlons des valeurs nulles concernant les jointures externes.

Nulls et OUTER JOIN

Lorsque vous joignez 2 tables, l'une des valeurs de l'une ou l'autre des tables peut être nulle. Pour les INNER JOIN, les enregistrements avec des valeurs nulles ne correspondront pas, et ils seront ignorés et n'apparaîtront pas dans le jeu de résultats. Si vous souhaitez obtenir les enregistrements qui ne correspondent pas, votre seule option est OUTER JOIN.

Pour en revenir aux antonymes, n'est-ce pas le contraire des INNER JOIN ? Pas entièrement, comme vous le verrez dans la section suivante.

Tout sur la jointure externe SQL Server

Comprendre les jointures externes commence par la sortie. Voici une liste complète de ce à quoi vous pouvez vous attendre :

• Tous les enregistrements qui correspondent à la condition de jointure ou au prédicat. C'est l'expression juste après le mot clé ON, un peu comme la sortie INNER JOIN. Nous appelons ce problème la ligne intérieure .
• Valeurs non NULL de la gauche table avec les contreparties nulles de la droite table. Nous appelons ce problème les lignes externes .
• Valeurs non NULL de la droite table avec les contreparties nulles de la gauche table. Il s'agit d'une autre forme de rangées extérieures.
• Enfin, il peut s'agir d'une combinaison de tout ce qui est décrit ci-dessus.

Avec cette liste, nous pouvons dire que OUTER JOIN renvoie les lignes internes et externes .

• Inner - parce que les résultats exacts de INNER JOIN peuvent être retourné.
• Outer – parce que les lignes extérieures peuvent également être retourné.

C'est la différence avec INNER JOIN.

LES JOINTS INTÉRIEURS RETOURNENT UNIQUEMENT LES LIGNES INTÉRIEURES. LES JOINTURES EXTERNES PEUVENT RENVOYER DES LIGNES INTERNES ET EXTERNES

Remarquez que j'ai utilisé "peut être" et "peut aussi être". Cela dépend de votre clause WHERE (ou si vous incluez une clause WHERE) si elle renvoie à la fois des lignes internes et/ou externes.

Mais à partir d'une instruction SELECT, comment pouvez-vous déterminer quelle est la table de gauche ou de droite ? Bonne question !

Comment savoir quelle est la table de gauche ou de droite dans une jointure ?

Nous pouvons répondre à cette question avec des exemples :

SELECT *
FROM Table1 a
LEFT OUTER JOIN Table2 b on a.column1 = b.column1

Dans l'exemple ci-dessus, Table1 est la table de gauche, et Table2 est la bonne table. Maintenant, prenons un autre exemple. Cette fois, il s'agit d'une simple jointure multiple.

SELECT *
FROM Table1 a
LEFT OUTER JOIN Table2 b on a.column1 = b.column1
LEFT OUTER JOIN Table3 c on b.column2 = c.column1

Dans ce cas, pour savoir ce qui est à gauche ou à droite, rappelez-vous qu'une jointure fonctionne sur 2 tables.

Tableau1 est toujours la table de gauche, et Table2 est la bonne table. Il s'agit de joindre 2 tables :Table1 et Table2 . Pourquoi ne pas rejoindre Table2 et Table3 ? Table2 devient la table de gauche, et Table3 est la bonne table.

Si nous ajoutons une quatrième table, Table3 devient la table de gauche, et Table4 est la bonne table. Mais cela ne s'arrête pas là. Nous pouvons joindre une autre table à la Table1 . Voici un exemple :

SELECT *
FROM Table1 a
LEFT OUTER JOIN Table2 b on a.column1 = b.column1
LEFT OUTER JOIN Table3 c on b.column2 = c.column1
LEFT OUTER JOIN Table4 d on c.column1 = d.column2
LEFT OUTER JOIN Table5 e on a.column2 = e.column1

Tableau1 est la table de gauche, et Table5 est la bonne table. Vous pouvez également faire de même avec les autres tables.

Bon, revenons à la liste des sorties attendues ci-dessus. Nous pouvons également en dériver les types de jointures externes.

Types de jointures externes

Il existe 3 types basés sur les sorties OUTER JOIN.

JOINTURE EXTERNE GAUCHE (JOINTURE GAUCHE)

LEFT JOIN renvoie les lignes internes + les valeurs non NULL de la gauche table avec les contreparties nulles de la table de droite. Par conséquent, il s'agit de LEFT JOIN car la table de gauche est la dominante des deux tables de la jointure ayant des valeurs non nulles.

EXEMPLE DE JOINTURE EXTERNE GAUCHE 1

-- Return all customerIDs with orders and no orders

USE AdventureWorks
GO

SELECT
 c.CustomerID
,soh.OrderDate
FROM Sales.Customer c
LEFT OUTER JOIN Sales.SalesOrderHeader soh ON c.CustomerID = soh.CustomerID 

Dans l'exemple ci-dessus, le Client est la table de gauche, et SalesOrderHeader est la bonne table. Le résultat de la requête est 32 166 enregistrements – il comprend à la fois les rangées intérieures et extérieures. Vous pouvez en voir une partie dans la figure 1 :

Supposons que nous souhaitions renvoyer uniquement les lignes extérieures ou les clients sans commande. Pour ce faire, ajoutez une clause WHERE pour inclure uniquement les lignes avec des valeurs nulles de SalesOrderHeader .

SELECT
 c.CustomerID
,soh.OrderDate
FROM Sales.Customer c
LEFT OUTER JOIN Sales.SalesOrderHeader soh ON c.CustomerID = soh.CustomerID
WHERE soh.SalesOrderID IS NULL

Le jeu de résultats que j'ai obtenu est 701 enregistrements . Tous aiment le null OrderDate de la Figure 1.

Si je n'obtiens que les lignes intérieures, le résultat sera 31 465 enregistrements . Je peux le faire en modifiant la clause WHERE pour inclure ces SalesOrderIDs qui ne sont pas nuls. Ou je peux changer la jointure en INNER JOIN et supprimer la clause WHERE.

Pour voir s'il extrait de la sortie du premier exemple sans la clause WHERE, résumons les enregistrements.

À partir du nombre total de lignes ci-dessus avec 32 166 enregistrements, vous pouvez voir qu'il vérifie avec les premiers résultats d'exemple. Cela montre également comment fonctionne LEFT OUTER JOIN.

EXEMPLE DE JOINTURE EXTERNE GAUCHE 2

Cette fois, l'exemple est une jointure multiple. Notez également que nous supprimons le mot-clé OUTER.

-- show the people with and without addresses from AdventureWorks
USE AdventureWorks
GO

SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
LEFT JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
LEFT JOIN Person.Address a ON bea.AddressID = a.AddressID
LEFT JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID 

Il a généré 19 996 enregistrements. Vous pouvez consulter la partie de la sortie dans la figure 2 ci-dessous. Les enregistrements avec AddressLine1 nul sont les rangées extérieures. Au-dessus se trouvent les rangées intérieures.

JOINTURE EXTERNE DROITE (JOINTURE DROITE)

RIGHT JOIN renvoie les lignes internes + les valeurs non NULL à partir de la droite table avec les contreparties nulles de la table de gauche.

EXEMPLE DE JOINTURE EXTERNE DROITE 1

-- From the product reviews, return the products without product reviews
USE AdventureWorks
GO

SELECT
P.Name
FROM Production.ProductReview pr
RIGHT OUTER JOIN Production.Product p ON pr.ProductID = p.ProductID
WHERE pr.ProductReviewID IS NULL 

La figure 3 montre 10 enregistrements sur 501 dans l'ensemble de résultats.

Dans l'exemple ci-dessus, ProductReview est le tableau de gauche, et le produit est la bonne table. Puisqu'il s'agit d'un RIGHT OUTER JOIN, nous avons l'intention d'inclure les valeurs non NULL de la table de droite.

Cependant, le choix entre LEFT JOIN ou RIGHT JOIN dépend de vous. Pourquoi? Parce que vous pouvez exprimer la requête, qu'elle soit LEFT ou RIGHT JOIN, et obtenir les mêmes résultats. Essayons avec un LEFT JOIN.

-- return the products without product reviews using LEFT OUTER JOIN
USE AdventureWorks
GO

SELECT
P.Name
FROM Production.Product p
LEFT OUTER JOIN Production.ProductReview pr ON pr.ProductID = p.ProductID
WHERE pr.ProductReviewID IS NULL

Essayez d'exécuter ce qui précède et vous obtiendrez le même résultat qu'à la figure 3. Mais pensez-vous que l'optimiseur de requête les traitera différemment ? Découvrons-le dans le plan d'exécution des deux à la figure 4.

Si vous êtes nouveau dans ce domaine, il y a quelques surprises dans le plan d'exécution.

1. Les diagrammes se ressemblent, et ils sont :essayez un Comparer Showplan , et vous verrez le même QueryPlanHash .
2. Remarquez le diagramme du haut avec une jointure de fusion. Nous avons utilisé un RIGHT OUTER JOIN, mais SQL Server l'a changé en LEFT OUTER JOIN. Il a également inversé les tables de gauche et de droite. Il le rend égal à la deuxième requête avec le LEFT JOIN.

Comme vous le voyez maintenant, les résultats sont les mêmes. Alors, choisissez lequel des OUTER JOIN sera le plus pratique.

Pourquoi SQL Server a-t-il remplacé RIGHT JOIN par LEFT JOIN ?

Le moteur de base de données n'a pas à suivre la façon dont vous exprimez les jointures logiques. Tant qu'il peut produire des résultats corrects de la manière la plus rapide qu'il pense possible, il apportera des modifications. Même les raccourcis.

Ne concluez pas que RGHT JOIN est mauvais et LEFT JOIN est bon.

EXEMPLE DE JOINTURE EXTERNE DROITE 2

Regardez l'exemple ci-dessous :

-- Get the unassigned addresses and the address types with no addresses
SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
RIGHT JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
RIGHT JOIN Person.Address a ON bea.AddressID = a.AddressID
RIGHT JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID
WHERE P.BusinessEntityID IS NULL 

Il y a 2 choses que vous pouvez obtenir à partir de cette requête, comme vous pouvez le voir dans la figure 5 ci-dessous :

Les résultats de la requête montrent ce qui suit :

1. Les adresses non attribuées - ces enregistrements sont ceux avec des noms nuls.
2. Types d'adresses sans adresse. Les types d'adresse Archive, Facturation et Principal n'ont pas d'adresse correspondante. Ce sont des enregistrements 817 à 819.

JOINTURE EXTERNE COMPLÈTE (JOINTURE COMPLÈTE)

FULL JOIN renvoie une combinaison de lignes internes et de lignes externes, gauche et droite.

-- Get people with and without addresses, unassigned addresses, and address types without addresses
SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
FULL JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
FULL JOIN Person.Address a ON bea.AddressID = a.AddressID
FULL JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID

L'ensemble de résultats comprend 20 815 enregistrements. Comme vous vous en doutez, il s'agit d'un nombre total d'enregistrements provenant de l'ensemble de résultats de INNER JOIN, LEFT JOIN et RIGHT JOIN.

LEFT et RIGHT JOIN incluent une clause WHERE pour afficher uniquement les résultats avec des valeurs NULL dans les tables de gauche ou de droite.

Notez que FULL JOIN peut produire un ensemble de résultats énorme à partir de grandes tables. Alors, utilisez-le uniquement lorsque vous en avez besoin uniquement.

Utilisations pratiques de OUTER JOIN

Si vous hésitez encore quand vous pouvez et devriez utiliser OUTER JOIN, voici quelques idées.

Jointures externes qui génèrent à la fois des lignes internes et externes

Des exemples peuvent être :

• Liste alphabétique des commandes clients payées et impayées.
• Liste alphabétique des employés en retard ou sans enregistrement de retard
• Une liste des assurés qui ont renouvelé et non renouvelé leurs polices d'assurance les plus récentes.

Jointures externes qui génèrent uniquement des lignes externes

Les exemples incluent :

• liste alphabétique des employés sans enregistrement de retard pour la prime zéro retard
• liste des territoires sans clients
• liste des agents commerciaux sans vente d'un produit particulier
• obtenir des résultats à partir de valeurs manquantes, comme des dates sans bons de commande dans une période donnée (exemple ci-dessous)
• nœuds sans enfant dans une relation parent-enfant (exemple ci-dessous)

Obtenir des résultats à partir des valeurs manquantes

Supposons que vous deviez produire un rapport. Ce rapport doit indiquer le nombre de jours pour chaque mois d'une période donnée où il n'y a pas eu de commandes. Le SalesOrderHeader dans AdventureWorks contient les dates de commande , mais ils n'ont pas de dates sans commandes. Que pouvez-vous faire ?

1. Créer un tableau de toutes les dates d'une période

Un exemple de script ci-dessous créera un tableau de dates pour toute l'année 2014 :

DECLARE @StartDate date = '20140101', @EndDate date = '20141231';

CREATE TABLE dbo.Dates
(
	d DATE NOT null PRIMARY KEY
)

WHILE @StartDate <= @EndDate
BEGIN
  INSERT Dates([d]) SELECT @StartDate;
  SET @StartDate = DATEADD(DAY, 1, @StartDate);
END

SELECT d FROM Dates ORDER BY [d];

2. Utilisez LEFT JOIN pour afficher les jours sans commandes

SELECT
 MONTH(d.d) AS [month]
,YEAR(d.d) AS [year]
,COUNT(*) AS NoOrderDays
FROM Dates d
LEFT JOIN Sales.SalesOrderHeader soh ON d.d = soh.OrderDate
WHERE soh.OrderDate IS NULL
GROUP BY YEAR(d.d), MONTH(d.d)
ORDER BY [year], [month]

Le code ci-dessus compte le nombre de jours pendant lesquels aucune commande n'a été passée. SalesOrderHeader contient les dates avec les commandes. Ainsi, les valeurs nulles renvoyées dans la jointure compteront comme des jours sans commandes.

En attendant, si vous souhaitez connaître les dates exactes, vous pouvez supprimer le décompte et le regroupement.

SELECT
 d.d
,soh.OrderDate
FROM Dates d
LEFT JOIN Sales.SalesOrderHeader soh ON d.d = soh.OrderDate
WHERE soh.OrderDate IS NULL

Ou, si vous souhaitez compter les commandes sur une période donnée et voir quelle date n'a aucune commande, voici comment :

SELECT DISTINCT
 D.d AS SalesDate
,COUNT(soh.OrderDate) AS NoOfOrders
FROM Dates d
LEFT JOIN Sales.SalesOrderHeader soh ON d.d = soh.OrderDate
WHERE d.d BETWEEN '02/01/2014' AND '02/28/2014'
GROUP BY d.d
ORDER BY d.d

Le code ci-dessus comptabilise les commandes de février 2014. Voir le résultat :

Pourquoi met-il en évidence le 3 février 2014 ? Dans ma copie d'AdventureWorks, il n'y a pas de bons de commande pour cette date.

Maintenant, remarquez COUNT(soh.OrderDate) dans le code. Plus tard, nous expliquerons pourquoi c'est si important.

Obtenir des nœuds sans enfant dans les relations parent-enfant

Parfois, nous avons besoin de connaître les nœuds sans enfant dans une relation parent-enfant.

Utilisons la base de données que j'ai utilisée dans mon article sur HierarchyID. Vous devez obtenir des nœuds sans enfants dans une table de relations parent-enfant à l'aide d'une jointure réflexive.

SELECT 
 r1.RankParentId
,r1.Rank AS RankParent
,r.RankId
FROM Ranks r
RIGHT JOIN Ranks r1 ON r.RankParentId = r1.RankId
WHERE r.RankId is NULL 

Mises en garde concernant l'utilisation de OUTER JOIN

Puisqu'un OUTER JOIN peut renvoyer des lignes internes comme un INNER JOIN, cela peut prêter à confusion. Les problèmes de performance peuvent aussi s'insinuer. Alors, notez les 3 points ci-dessous (j'y reviens de temps en temps - je ne rajeunis pas, donc j'oublie aussi).

Filtrer la table de droite dans un LEFT JOIN avec une valeur non nulle dans la clause WHERE

Cela peut poser problème si vous avez utilisé un LEFT OUTER JOIN mais que vous avez filtré la bonne table avec une valeur non nulle dans la clause WHERE. La raison en est qu'il deviendra fonctionnellement équivalent à un INNER JOIN. Prenons l'exemple ci-dessous :

USE AdventureWorks
GO

SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
LEFT JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
LEFT JOIN Person.Address a ON bea.AddressID = a.AddressID
LEFT JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID
WHERE bea.AddressTypeID = 5 

À partir du code ci-dessus, examinons les 2 tables :Person et BusinessEntityAddress . La personne est la table de gauche, et BusinessEntityAddress est la bonne table.

LEFT JOIN est utilisé, il suppose donc un BusinessEntityID nul quelque part dans BusinessEntityAddress . Ici, notez la clause WHERE. Il filtre la bonne table avec AddressTypeID =5. Il supprime complètement toutes les lignes externes dans BusinessEntityAddress .

Cela peut être l'un ou l'autre :

• Le développeur teste quelque chose dans le résultat mais a oublié de le supprimer.
• INNER JOIN était prévu, mais pour une raison quelconque, LEFT JOIN a été utilisé.
• Le développeur ne comprend pas la différence entre LEFT JOIN et INNER JOIN. Il suppose que l'un des 2 fonctionnera, et cela n'a pas d'importance car les résultats sont les mêmes dans ce cas.

L'un des 3 ci-dessus est mauvais, mais la troisième entrée a une autre implication. Comparons le code ci-dessus avec l'équivalent INNER JOIN :

SELECT
 P.FirstName
,P.MiddleName
,P.LastName
,a.AddressLine1
,a.AddressLine2
,a.City
,adt.Name AS AddressType
FROM Person.Person p
INNER JOIN Person.BusinessEntityAddress bea ON P.BusinessEntityID = bea.BusinessEntityID
INNER JOIN Person.Address a ON bea.AddressID = a.AddressID
INNER JOIN person.AddressType adt ON bea.AddressTypeID = adt.AddressTypeID
WHERE bea.AddressTypeID = 5

Il ressemble au code précédent, à l'exception du type de jointure. Le résultat est également le même, mais vous devez noter les lectures logiques dans STATISTICS IO :

Dans la figure 7, les premières statistiques d'E/S proviennent de l'utilisation de INNER JOIN. Un total de lectures logiques est de 177. Cependant, les deuxièmes statistiques concernent le LEFT JOIN avec une valeur de lecture logique supérieure de 223. Ainsi, une mauvaise utilisation de LEFT JOIN dans cet exemple nécessitera plus de pages ou de ressources de SQL Server. Par conséquent, il fonctionnera plus lentement.

À emporter

Si vous avez l'intention de générer des lignes internes, utilisez INNER JOIN. Sinon, ne filtrez pas la table de droite dans un LEFT JOIN avec une valeur non nulle. Si cela se produit, vous vous retrouvez avec une requête plus lente que si vous utilisiez INNER JOIN.

CONSEIL EN PRIME  :Cette situation se produit également dans un RIGHT JOIN lorsque la table de gauche est filtrée avec une valeur non nulle.

Utilisation incorrecte des types de jointure dans une jointure multiple

Supposons que nous voulions obtenir tous les fournisseurs et le nombre de bons de commande de produits pour chacun. Voici le code :

USE AdventureWorks
GO

SELECT
 v.BusinessEntityID
,v.Name AS Vendor
,pod.ProductID
,pod.OrderQty
FROM Purchasing.Vendor v
LEFT JOIN Purchasing.PurchaseOrderHeader poh ON v.BusinessEntityID = poh.VendorID
LEFT JOIN Purchasing.PurchaseOrderDetail pod ON poh.PurchaseOrderID = pod.PurchaseOrderID 

Le code ci-dessus renvoie à la fois les fournisseurs avec des bons de commande et ceux qui n'en ont pas. La figure 8 montre le plan d'exécution réel du code ci-dessus.

En pensant que chaque bon de commande a un détail de bon de commande garanti, un INNER JOIN serait préférable. Cependant, est-ce vraiment le cas ?

Tout d'abord, prenons le code modifié avec le INNER JOIN.

USE AdventureWorks
GO

SELECT
 v.BusinessEntityID
,v.Name AS Vendor
,pod.ProductID
,pod.OrderQty
FROM Purchasing.Vendor v
LEFT JOIN Purchasing.PurchaseOrderHeader poh ON v.BusinessEntityID = poh.VendorID
INNER JOIN Purchasing.PurchaseOrderDetail pod ON poh.PurchaseOrderID = pod.PurchaseOrderID 

N'oubliez pas que l'exigence ci-dessus indique « tous » les fournisseurs. Puisque nous avons utilisé le LEFT JOIN dans le code précédent, nous obtiendrons des fournisseurs sans bons de commande retournés. C'est à cause de la valeur nulle PurchaseOrderID .

Changer la jointure en INNER JOIN supprimera tous les PurchaseOrderIDs. nuls. Cela annulera également tous les VendorIDs nuls du fournisseur table. En effet, cela devient un INNER JOIN.

Est-ce une hypothèse correcte ? Le plan d'exécution révélera la réponse :

Comme vous le voyez, toutes les tables ont été traitées à l'aide de INNER JOIN. Par conséquent, notre hypothèse est correcte. Mais pour le pire, le jeu de résultats est maintenant incorrect car les fournisseurs sans commande n'ont pas été inclus.

À emporter

Comme dans le cas précédent, si vous souhaitez un INNER JOIN, utilisez-le. Mais vous savez quoi faire si vous rencontrez une situation comme celle-ci.

Dans ce cas, un INNER JOIN supprimera toutes les lignes externes jusqu'à la table supérieure de la relation. Même si votre autre jointure est une LEFT JOIN, cela n'aura pas d'importance. Nous l'avons prouvé dans les plans d'exécution.

Utilisation incorrecte de COUNT() dans les jointures externes

Vous souvenez-vous de notre exemple de code qui compte le nombre de commandes par date et le résultat de la figure 6 ?

Ici, nous expliquerons pourquoi le 03/02/2014 est mis en surbrillance et sa relation avec COUNT(soh.OrderDate) .

Si vous essayez d'utiliser COUNT(*), le nombre de commandes pour cette date devient 1, ce qui est faux. Il n'y a pas de commandes à cette date. Ainsi, lorsque vous utilisez COUNT() avec une OUTER JOIN, utilisez la bonne colonne pour compter.

Dans notre cas, soh.OrderDate peut être nul ou non. Lorsqu'il n'est pas nul, COUNT() inclura la ligne dans le décompte. COUNT(*) lui fera tout compter, y compris les valeurs nulles. Et à la fin, de mauvais résultats.

Les points à retenir de l'OUTER JOIN

Résumons les points :

• OUTER JOIN peut renvoyer à la fois des lignes internes et des lignes externes. Les lignes internes sont le résultat similaire au résultat de INNER JOIN. Les lignes externes sont les valeurs non nulles avec leurs homologues nuls en fonction de la condition de jointure.
• OUTER JOIN peut être LEFT, RIGHT ou FULL. Nous avions des exemples pour chacun.
• Les lignes externes renvoyées par OUTER JOIN peuvent être utilisées de diverses manières pratiques. Nous avons eu des idées sur le moment où vous pouvez utiliser ce matériel.
• Nous avions également des mises en garde concernant l'utilisation de OUTER JOIN. Tenez compte des 3 points ci-dessus pour éviter les bugs et les problèmes de performances.

La dernière partie de cette série traitera de CROSS JOIN. Donc, jusque-là. Et si vous aimez ce post, partagez un peu d'amour en cliquant sur les boutons des réseaux sociaux. Bon codage !