Dans cet article, nous allons briser certains des mythes courants que nous avons habituellement lorsque nous travaillons sur SQL - Structured Query Language. Nous utiliserons le serveur de base de données MS SQL Server pour écrire nos requêtes.
1. La clause HAVING ne peut pas être utilisée sans la clause GROUP BY !
Vous devez vous demander si le AYANT La clause peut être utilisée dans une requête sans utiliser la PAR GROUPE Clause!
Pourquoi cette question se pose-t-elle même ? Parce que nous avons appris : « HAVING est utilisé avec GROUP BY ». Venons-en à la réponse !
Nous pouvons certainement "utiliser la clause HAVING dans une requête sans même utiliser la clause GROUP BY", mais cela n'a pas vraiment de sens car il n'y a pas de cas d'utilisation pratique de cette requête. Pourquoi?
Parce que HAVING est utilisé pour filtrer les données après les avoir regroupées par rapport à une colonne particulière de la table
Vous voulez voir comment ?
Considérez la table ORDERS avec des colonnes telles que Order_Id, Category, Product et Sales
SÉLECTIONNER * DES COMMANDES
AVOIR sans GROUPE PAR
Nous écrivons la requête sous la forme :
SELECT AVG(Sales) AS Avg_Sales FROM ORDERS HAVING AVG(Sales) > 500
Nous obtenons la sortie comme suit :
Donc techniquement, comme nous pouvons le voir, HAVING fonctionne parfaitement sans GROUP BY mais nous ne pouvons pas vraiment analyser grand-chose à partir de cela.
2. Une clé étrangère est nécessaire pour joindre 2 tables !
Vous devez vous demander si une relation clé primaire-étrangère est nécessaire entre 2 tables pour rejoindre Eux.
Prenons un exemple. Nous avons 2 tableaux :
Tableau Employé : Il contient les détails des différents employés du service technique de l'organisation "ABC".
Table Courses : elle contient le Course_Id des cours suivis par différents employés de l'organisation "ABC"
Comme nous pouvons le voir, aucune relation n'existe entre l'employé de la table et les cours de la table. (E_Id n'est pas une clé étrangère car elle ne tire pas ses valeurs de la colonne E_Id de la table Employee.)
Ecriture d'une requête pour joindre les 2 tables :
SELECT E.E_Id , E_Name , Department ,Salary , Course_Id FROM Employé E INNER JOIN Cours C ON E.E_Id = C.E_Id
Nous obtenons la sortie comme suit :
Comme on peut le voir: Ce mythe est brisé!
Nous sommes en mesure de joindre les 2 tables sans clé primaire/étrangère uniquement sur la base d'une colonne avec le même type de données (colonne E_Id)
Que pouvons-nous conclure ?
Joindre 2 tables :
Nous n'avons pas besoin de clé primaire.
Nous n'avons pas besoin d'une clé étrangère.
Nous n'exigeons pas que les tables aient une relation.
Nous pouvons joindre 2 tables sur n'importe quelle(s) colonne(s) ayant le même type de données.
3. SELF est le mot clé utilisé pour mettre un SELF JOIN !
Pour toutes les autres jointures, nous avons des mots-clés comme INNER JOIN, LEFT JOIN. JOINTURE DROITE et JOINTURE COMPLÈTE. Vous devez vous demander quel est le mot-clé d'un SELF JOIN !
Brisons le mythe !
Il n’y a pas de limite de temps pour le tournoi. Cependant, si vous restez inactif pendant une longue période, vous serez déconnecté de BBO et la partie sera perdue. aucune mot-clé pour mettre un AUTO-JOINTURE. SELF JOIN signifie joindre une table avec elle-même sur n'importe quelle colonne. Ici 2 alias de la même table sont créés. Prenons un exemple :
Considérez le tableau suivant : Employé
Prenons une question. Afficher le nom des employés appartenant au même service.
Ici, la table Employee doit être jointe à elle-même. Pour effectuer une auto-jointure ici, nous pouvons écrire la requête comme suit :
SELECT A.E_Name AS EMP1 , B.E_Name AS EMP2 , A.Department FROM Employé A , Employé B WHERE A.E_Id B.E_Id AND A.Department = B.Department
Il convient de noter que nous n'avons utilisé aucun mot-clé pour effectuer la SELF JOIN ici, au lieu que des alias de table aient été créés et utilisés pour réellement joindre la table Employee avec elle-même.
4. La clause ORDER BY ne peut pas être utilisée dans une sous-requête !
Considérons d'abord 2 exemples :
Considérez le tableau : COMMANDES
Exemple 1:
Nous souhaitons afficher toutes les données du tableau et des colonnes supplémentaires indiquant les produits classés par ventes dans l'ordre croissant. Pour cela nous pouvons écrire une requête :
SELECT * , (SELECT Produit , Ventes FROM ORDERS ORDER BY Sales) FROM ORDERS
Mais ici nous obtenons une erreur !!!
"La clause ORDER BY n'est pas valide dans les vues, les fonctions en ligne, les tables dérivées, les sous-requêtes et les expressions de table communes, sauf si TOP, OFFSET ou FOR XML est également spécifié"
Mais pourquoi cette erreur ?
Dans ce cas, la sous-requête (SELECT Product, Sales FROM ORDERS ORDER BY Sales) renvoie plusieurs lignes.
Exemple 2:
Supposons que j'écrive une requête du type :
SELECT Product , (SELECT TOP 1 Product FROM ORDERS ORDER BY Sales) AS Highest_Sale FROM ORDERS
Cette requête fonctionne !
Dans ce cas, la sous-requête (SELECT TOP 1 Product FROM ORDERS ORDER BY Sales) renvoie une seule ligne (en raison du mot-clé TOP utilisé).
Nous obtenons donc cela : Dans l'exemple 1, la clause ORDER BY ne fonctionne pas dans la sous-requête. Alors que dans l'exemple 2, la clause ORDER BY fonctionne dans la sous-requête. Mais avez-vous remarqué quelque chose là-bas?
-
Haut mot-clé a été utilisé dans la requête.
-
Nous ne pouvons pas vraiment analyser quoi que ce soit à partir de la requête. Ainsi, aucune information utile ne peut être dérivée de la requête.
Conclusion
A quoi pouvons-nous penser ?
Nous savons déjà que la sortie de la requête interne (la sous-requête) est utilisée comme entrée pour la requête externe (la requête principale), il n'est donc pas nécessaire que nous ordonnions les valeurs dans la sous-requête car nous devons de toute façon le faire dans la requête externe. Par conséquent, il n'est pas très utile d'utiliser la clause ORDER BY dans la sous-requête.
Que dit SQL ?
La clause ORDER BY n'est pas valide dans les vues, les fonctions en ligne, les tables dérivées, les sous-requêtes et les expressions de table communes, sauf si TOP, OFFSET ou FOR XML est également spécifié. Il est donc préférable de ne pas utiliser la clause ORDER BY dans une sous-requête car :
-
Il ne fournit aucune information précieuse.
-
Ne peut être utilisé qu'avec les clauses TOP, OFFSET et FOR XML
5. La clause WHERE et la clause HAVING peuvent être utilisées de manière interchangeable !
Considérez la table ORDERS avec des colonnes telles que Order_Id, Category, Product et Sales
SÉLECTIONNER * DES COMMANDES
Supposons que nous voulions voir les produits dont les ventes sont supérieures à 500. Nous écrirons la requête comme suit :
SELECT Produit , Ventes FROM ORDERS WHERE Ventes > 500
Nous obtenons la sortie comme suit :
Supposons que nous voulions voir les catégories dont les ventes sont supérieures à 500. Nous écrirons la requête comme suit :
SELECT Category , SUM(Sales) AS SALES FROM ORDERS GROUP BY Category HAVING SUM(Sales) > 500
Nous obtenons la sortie comme suit :
Dans les deux cas, nous devons filtrer les enregistrements sur la base d'une condition, mais le niveau est différent.
Lorsque nous voulons voir les catégories, nous devons regrouper les données, c'est-à-dire que nous prenons tous les produits entrant dans une catégorie et créons un groupe. Lorsque nous voulons voir les produits, aucun regroupement n'est requis.
Que pouvons-nous conclure?
La clause WHERE et la clause HAVING ne peuvent pas être utilisées de manière interchangeable. Les deux sont utilisés pour filtrer les enregistrements d'une table mais à différents niveaux.
clause WHERE: utilisé pour filtrer les enregistrements de la table en fonction de la condition spécifiée.
Clause AVOIR: Utilisé pour filtrer les enregistrements des groupes formés en fonction de la condition spécifiée.
6. Choisir "quel JOIN mettre quand" n'est PAS un gros problème !
Il existe différents types de jointures qui peuvent être placées sur les tables pour obtenir les résultats souhaités, à savoir : Left Join, Right Join, Inner Join, Full Join, Self Join, Cross Join, Natural Join, etc.
Est-ce que toutes ces jointures donnent le même résultat ? Pouvons-nous utiliser ces jointures de manière interchangeable ? L'utilisation de l'une de ces jointures dans n'importe quelle situation servira notre objectif ? Vous voulez des réponses à ces questions ?
Prenons d'abord une situation, nous avons 2 tableaux :
Tableau : Client
Tableau : Commandes
Affichez les détails de tous les clients qui ont passé la commande.
Comment allons-nous résoudre ce problème ? Nous devons mettre une jointure pour récupérer les données de ces 2 tables. Mais quelle jointure faut-il mettre dans ce cas ?
Essayons d'abord LEFT JOIN ! La requête peut s'écrire :
SELECT * FROM Client LEFT JOIN Commandes ON Cust_Id = Order_Id
Cela donne la sortie suivante:
Nous obtenons les détails de tous les clients à partir de la table Client. Bien que nous puissions obtenir des informations sur les clients qui ont passé une commande en voyant les valeurs NULL dans la colonne Order_Id, cela nécessite un travail manuel.
Ne fonctionne pas!
Essayons RIGHT JOIN maintenant. La requête peut s'écrire :
SELECT * FROM Client RIGHT JOIN Commandes ON Cust_Id = Order_Id
Cela donne la sortie suivante:
Comme voulu!
Nous n'obtenons les détails que des clients qui ont passé une commande, c'est-à-dire qui ont un enregistrement correspondant dans la table Commandes. Puisque nous voulons tous les enregistrements de la table Orders et les enregistrements correspondants de la table Customer afin que nous puissions obtenir les détails des seuls clients qui ont passé une commande et qui se trouvent donc dans la table Orders. Donc, dans ce scénario, nous allons utiliser le RIGHT JOIN.
Que pouvons-nous conclure?
Mettre la bonne jointure peut nous aider à économiser beaucoup de temps et d'énergie ! Nous devons savoir quelle jointure appliquer dans quel scénario. C'est un concept très important qui nous facilite la vie lors de l'interrogation des données !
Apprenons un peu sur les jointures les plus fréquemment utilisées :
-
(INNER) JOIN : il récupère les enregistrements qui ont des valeurs correspondantes dans les deux tables impliquées dans la jointure.
-
LEFT (OUTER) JOIN : il récupère tous les enregistrements de la table de gauche et les enregistrements correspondants correspondants de la table de droite.
-
JOINTURE DROITE (EXTÉRIEURE) : elle récupère tous les enregistrements de la table de gauche et les enregistrements correspondants correspondants de la table de droite.
-
FULL (OUTER) JOIN : il récupère tous les enregistrements des deux tables, qu'il y ait une correspondance ou non.
J'espère donc que cet article a brisé certains de vos mythes concernant SQL. Si vous avez encore des questions concernant ces mythes, faites-le moi savoir dans les commentaires ci-dessous. Nous pouvons y discuter rapidement.
Pour approfondir vos connaissances vous pouvez vous référer à l'article : https://www.analyticsvidhya.com/blog/2020/07/sql-functions-for-data-analysis-tasks/
Vous pouvez me joindre sur LinkedIn : https://www.linkedin.com/in/ayushi-gupta25/
