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 :
- ;