Jointure avec solutions vides

Bonjour,

J'ai un problème de jointure :

Voici ma 1ère table (table1) :

Code:

---

1 2 3 4 5 6

DATE 01/01/2023 02/01/2023 03/01/2023 ...

---

Et ma 2ème (table2) :

Code:

---

1 2 3 4 5 6 7

DATE PRODUIT QUANTITE 01/01/2023 A 2 02/01/2023 A 1 02/01/2023 B 3 03/01/2023 A 5 03/01/2023 B 6

---

Et ce à quoi j'aimerai arriver :

Code:

---

1 2 3 4 5 6 7 8

DATE PRODUIT QUANTITE 01/01/2023 A 2 01/01/2023 B NULL 02/01/2023 A 1 02/01/2023 B 3 03/01/2023 A 5 03/01/2023 B 6

---

Mais j'ai beau me creuser la tête je n'y arrive pas...

Help !

D'avance merci ;-)

Bonjour,
Sans avoir de table qui liste les produits (donc sans notion de date), ça me semble difficile.

Sinon en renommant les tables pour plus de clarté, ça donnerai une requête de ce genre:

Code:

---

1 2 3 4 5 6 7

select calendrier.ColDate, produit.Code,sum(vente.Quantite) from Calendrier cross join Article left outer join Vente on Vente.idCal = Calendrier.id and Vente.idPdt = Produit.id group by calendrier.ColDate, produit.Code

---

Tu auras ainsi toutes les dates, tous les articles et pour chaque couple date/code article le cumul des ventes.

Sans la table article, tu pourrais partir de la liste des codes présents dans la table des ventes, mais un article jamais vendu n'apparaitra pas.

Tatayo.

Bonjour,

Ce que tu veux faire s'appelle une jointure externe partitionnée dans Oracle (ça n'existe pas dans les autres SGBD). Voici la syntaxe:

Code:

---

1 2 3 4 5 6

select table1.date_evt, table2.produit, table2.quantite from table2 partition by (produit) right join table1 on (table1.date_evt = table2.date_evt) order by 1, 2;

---

Simple comme bonjour en pur SQL :

Soit les tables :

Code:

---

1 2 3 4 5 6

CREATE TABLE TA (D DATE) INSERT INTO TA VALUES ('2023-01-01') , ('2023-01-02') , ('2023-01-03'); CREATE TABLE TB (D DATE, PRODUIT VARCHAR(16), QUANTITE INT); INSERT INTO TB VALUES ('2023-01-01', 'A', 2) , ('2023-01-02', 'A', 1) , ('2023-01-02', 'B', 3) , ('2023-01-03', 'A', 5) , ('2023-01-03', 'B', 5);

---

La solution :

Code:

---

1 2 3 4 5

SELECT DISTINCT TA.D, T.PRODUIT, TB.QUANTITE FROM TA CROSS JOIN (SELECT PRODUIT FROM TB) AS T LEFT OUTER JOIN TB ON TA.D = TB.D AND T.PRODUIT = TB.PRODUIT

---

A +

C'est beaucoup moins performant que la jointure externe partitionnée.
NB : dans le cross join il faut select distinct produit from tb.

Parlons en de l'optimiseur d'Oracle !!!!

C'est donc du fait d'un défaut de l'optimiseur d'Oracle, que l'on ajoute une syntaxe inutile pour palier les défaut de ce SGBDR....

Je doute que cela soit un jour normalisé !

A +

En environnement dataware (ou big data), c'est une demande extrêmement courante.

En terme de perf, on évite de lire deux fois la table des faits, je t'assure ça scale beaucoup mieux chez Oracle avec cette syntaxe (et je dirai kifkif entre les deux SGBD avec le SQL normatif).

Plan Oracle DB :

------------------------------------------------------------------------------------
| Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |      |     5 |   160 |     9  (23)| 00:00:01 |
|   1 |  VIEW                       |      |     5 |   160 |     9  (23)| 00:00:01 |
|   2 |   MERGE JOIN PARTITION OUTER|      |     5 |   205 |     9  (23)| 00:00:01 |
|   3 |    SORT JOIN                |      |     3 |    27 |     4  (25)| 00:00:01 |
|   4 |     TABLE ACCESS FULL       | TA   |     3 |    27 |     3   (0)| 00:00:01 |
|*  5 |    SORT PARTITION JOIN      |      |     5 |   160 |     4  (25)| 00:00:01 |
|   6 |     TABLE ACCESS FULL       | TB   |     5 |   160 |     3   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Plan MS SQL-Server :

  |--Nested Loops(Left Outer Join, WHERE:([dbo].[TA].[D]=[dbo].[TB].[D] AND [dbo].[TB].[PRODUIT]=[dbo].[TB].[PRODUIT]))
       |--Nested Loops(Inner Join)
       |    |--Sort(DISTINCT ORDER BY:([dbo].[TB].[PRODUIT] ASC))
       |    |    |--Table Scan(OBJECT:([dbo].[TB]))
       |    |--Table Scan(OBJECT:([dbo].[TA]))
       |--Table Scan(OBJECT:([dbo].[TB]))

Je pense que les taquineries sur les performances de tel ou tel SGBD, ça ne répond pas à la question initiale.

ici, la démarche (pédagogique) est la suivante :
1) recenser tous les produits qui doivent apparaître dans la requête finale.
2) bâtir la requête voulue.

Et je trouve que les CTE, c'est très pratique sur le plan pédagogique. Après, si on s'inquiète des performances, on peut discuter.

On peut même ajouter une étape intermédiaire :
1) recenser toutes les lignes de table2 qui ont une date qui nous intéresse (On va appeler cette table 'virtuelle' Univers_travail )
2) recenser tous les produits qui doivent apparaître dans la requête finale, c'est à dire tous les produits qui apparaissent dans cette table virtuelle Univers_travail
3) bâtir la requête voulue.

En effet, on a une liste de dates (dans table1) , par exemple tous les jours de janvier, et dans table2, on a tout l'historique, pas uniquement janvier.

1) création de la table virtuelle Univers_travail :
select * from table2 where qdate in ( select qdate from table1)

2) recenser tous les produits qui doivent apparaître dans la requête finale
select distinct idProduit from Univers_travail

3) recenser toutes les lignes qui doivent apparaître dans le tableau final : le croisement de la liste de toutes les dates et de tous les idProduit

4) on colle toutes les pièces du puzzle :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

with univers_travail as ( select * from table2 where qdate in ( select qdate from table1) ) , univers_produit as ( select distinct idProduit from Univers_travail ) , univers_final as ( select T1.qdate, P.idProduit from table1 T1, univers_produit P ) select F.qdate, F.idProduit, T.quantite from univers_final F left join univers_travail T on T.idProduit = F.idProduit and T.qdate =F.qdate

---

Avec cette clause WITH, en décomposant pas à pas, on arrive à tout faire.
Je n'aborde pas l'aspect performance. On est entre 'bricoleurs du dimanche'.