Problème : manipulations quasi-exclusives sur une année donnée => tables .
- Comment requêter plusieurs années en même temps ?
- Opérations d'ensembles sur ensemble d'entrées (idéalement même colonnes) :
- : concaténer les lignes [avec doublons].
- : les lignes communes aux deux requêtes.
- : les lignes de la première requête absentes de la seconde.
- sous requête : utiliser une requête dans une autre requête.
- 💡 Un ensemble d'entrées (placées entre parenthèses) peuvent remplacer :
- une table dans une clause ;
- une liste (si une seule colonne) ;
- un scalaire (si une seule ligne et colonne).
Retourne vrai si comparaison vraie pour au moins un élément de la liste.
Certains SGBD requièrent d'ajouter entre l'opérateur de comparaison et la liste.
- Sous requête corrélée : la sous-requête dépend de la requête principale.
- 💡 requête non-corrélée : sous-requête exécutée une unique fois.
- ⚠ requête correlée : réexécutée à chaque ligne de la requête principale.
- ⚠ Il faut les éviter autant que possible...
- ⚠ Ne pas calculer toutes les lignes, s'arrêter le plus tôt possible.
- à la place de .
- / ou à la place de certaines fonctions d'agrégations.
Problème : Table référence table .
- comment obtenir :
- la liste des vendeurs ayant au moins 10 ventes.
- la liste des ventes des vendeurs embauchés il y a moins de 5 ans.
- requêtes corrélées :
- syntaxe lourde ;
- peu performant.
Solution : les jointures ≈ fusionne des entrées de différentes tables.
- Produit cartésien : table intermédiaire, combine toutes les entrées de et .
- (e.g. )
- sur table intermédiaire ⇒ majorité des entrées intermédiaires inutiles !
T1.ID == T2.ID
- ⚠ Même sur de petites tables, la table intermédiaire explose très vite :
| # Entrées | # Tables | # Table intermédiaire | # Résultats |
|---|---|---|---|
| E | T | E^T | E |
| 1 000 | 2 | 1 000 000 | 1 000 |
| 1 000 | 3 | 1 000 000 000 | 1 000 |
| 32 000 | 2 | 1 024 000 000 | 32 000 |
| 1 000 | 6 | 10^18 | 1 000 |
| 1 000 000 | 3 | 10^18 | 1 000 000 |
- ⚠ 1 milliard de lignes ≈ plusieurs Go, et 10^18 ≈ plusieurs Po !!!
- ⚠ On n'utilise JAMAIS les produits cartésien en SQL ! JA-MAIS !
- Jointure : construit la table intermédiaire plus intelligemment :
- Pour chaque entrée de (FK), recherche l'entrée de (PK) correspondant.
- bien plus rapide et moins coûteux en mémoire.
- ⚠ basé sur les colonnes de noms identiques entre et
- Pour chaque entrée de (FK), recherche l'entrée de (PK) correspondant.
- 💡 Recherche des entrées de : si index ( ou PK) ⇒ quasi instantané.
- ⚠ Fortement recommandé d'effectuer des jointures sur des index.
- ⚠ exécuté après jointure.
- 💡 SGBD peuvent optimiser en préfiltrant, lorsque possible, avant jointures.
Il existe 3 types de jointures fréquemment utilisées :
- : , par défaut.
- : + entrées de dont aucune entrée de ne correspond.
- : + entrées de dont aucune entrée de ne correspond.
⚠ Il existe 2 autres types de jointures, à éviter :
- : ⇔ (pour des raisons de lisibilité, préférez )
- : produit cartésien (à éviter).
Problème : et ont des colonnes identiques, autres que celles de jointures.
Solution :
- Éviter les jointures , et expliciter les colonnes de jointure :
- ;
- Renommer les colonnes homonymes :
- ;
Problème : les colonnes de jointure ont des noms différents dans et .
Solution : Préciser la condition de jointure :
- ;