Votre guide intermédiaire de SQL

Plus vous vous familiarisez avec SQL, plus vous serez en mesure d'effectuer des requêtes encore
plus avancées. Ce guide détaillé vous permettra de découvrir plus en détail certaines des fonctions
SQL que vous avez
déjà découvertes et vous donnera de nouveaux outils pour travailler. N'oubliez pas de sauvegarder ce
guide, afin de pouvoir vous référer facilement à ces conseils utiles à l'avenir.

Structure SQL pour les requêtes plus complexes

Vous en apprendrez davantage sur ces clauses et expressions dans les sections ci-dessous, mais
voyons d'abord comment vous pourriez structurer une requête SQL plus complexe :

SELECT Colonne que vous voulez regarder

FROM Tableau dans lequel se trouvent les données
WHERE Certaines conditions relatives aux données
GROUP BY Colonne que vous voulez agréger
HAVING Certaines conditions relatives à l'agrégation

ORDER BY Colonne avec laquelle vous souhaitez classer les résultats

et dans l’ordre ASCendant ou DESCendant
LIMIT Le nombre maximal de lignes que vous voulez
que vos résultats contiennent

Différents types de JOIN

La plupart des analystes utiliseront soit les INNER JOIN, soit les LEFT JOIN tout au long de leur
carrière. Lorsque vous joignez des tableaux, vous combinez les données d'un tableau avec celles
d'un autre tableau reliées par un champ commun. Par exemple, disons que vous avez les couleurs
préférées de vos amis dans un tableau et les films préférés de vos amis dans un autre tableau. Vous
pouvez avoir leurs deux couleurs et films préférés dans un seul tableau en joignant les deux
tableaux sur les noms de vos amis qui est le champ qu'ils ont en commun. Il s'agit de votre champ
JOIN. Dans le monde du travail, un champ JOIN est généralement une sorte d'identifiant, par
exemple un customer_id ou account_id.

Aperçu du tableau
Favorite_Colors Favorite_Movies

friend (chaîne) friend (chaîne)

color (chaîne) movie (chaîne)

Aperçu des données

Favorite_Colors

friend color

Rachel DeSantos blue

Sujin Lee green

Najil Okoro red

John Anderson orange

Favorite_Movies

friend movie

Rachel DeSantos Avengers

Sujin Lee Despicable Me

Najil Okoro Frozen

Ainsi, dans cet exemple, il est préférable d'utiliser un INNER JOIN si vous souhaitez uniquement
consulter les informations relatives aux amis qui ont à la fois une couleur et un film préférés. Cela signifie
que si John Anderson a une couleur préférée mais pas de film préféré, John Anderson n'apparaîtra pas
dans vos résultats. Les amis doivent être dans les deux tableaux pour apparaître dans vos résultats. Les
INNER JOIN sont donc utiles lorsque vous voulez voir les données où la clé JOIN existe dans les deux
tableaux, ce qui est généralement la raison pour laquelle vous voulez joindre des jeux de données en
premier lieu. En général, les analystes utilisent les INNER JOIN la plupart du temps.

SELECT
friend,
color,
movie
FROM
Favorite_Colors AS c
INNER JOIN
Favorite_Movies AS m ON [Link] = [Link]
Résultats :

friend color movie

Rachel DeSantos blue Avengers

Sujin Lee green Despicable Me

Najil Okoro red Frozen

Du fait que cette requête a utilisé un INNER JOIN, les résultats ne contiennent que trois des quatre
amis. Pour rappel, cela s'explique par le fait que les requêtes INNER JOIN ne renvoient que les
résultats dans lesquels le champ JOIN, dans ce cas "friend", existe dans les deux tableaux. John
Anderson n'existant pas dans le tableau des films préférés, il est exclu des résultats de la requête.

Supposons maintenant que vous souhaitiez utiliser un LEFT JOIN pour rassembler les informations
relatives à tous vos amis dans un tableau (par exemple, le tableau des couleurs préférées) en y
ajoutant les données de l'autre tableau (par exemple, le tableau des films préférés) s’il existe. Ainsi,
si John Anderson a une couleur préférée mais pas de film préféré, il apparaîtra quand même dans
vos résultats. Il aura juste un champ vide (qui est null) pour son film préféré. La plupart du temps, les
LEFT JOIN sont utilisés si les données que vous essayez d'extraire d'un autre tableau sont
facultatives. Il s'agit d'un champ utile mais non nécessaire pour votre analyse, car vous risquez
d'obtenir des valeurs null. Sur le terrain, vous constaterez que les analystes utilisent moins souvent
LEFT JOIN que INNER JOIN.

SELECT
friend,
color,
movie
FROM
Favorite_Colors AS c
LEFT JOIN
Favorite_Movies AS m ON [Link] = [Link]

Résultats :

friend color movie

Rachel DeSantos blue Avengers

Sujin Lee green Despicable Me

Najil Okoro red Frozen

John Anderson orange null

Vous connaissez maintenant la différence entre les INNER JOIN et les LEFT JOIN. Vous savez que
les INNER JOIN seront les types de JOIN les plus utilisés car ils correspondent généralement aux cas
d'utilisation de l'entreprise.
Une autre raison pour laquelle les INNER JOIN sont utilisés est qu'ils génèrent moins de données puisque
la clé JOIN doit exister dans les deux tableaux. Cela signifie que les requêtes avec des INNER JOIN ont
tendance à s'exécuter plus rapidement et à utiliser moins de ressources que les requêtes avec des LEFT
JOIN. Ce n'est peut-être pas un problème pour la plupart des analystes, mais si vous travaillez avec de
très grands tableaux comportant plus d'un million de lignes et/ou en fonction du dialecte SQL utilisé,
l'exécution de votre requête peut durer beaucoup plus longtemps si vous utilisez un LEFT JOIN au lieu
d'un INNER JOIN.

Fondamentalement, il s'agit d'utiliser les INNER JOIN autant que possible.

Agrégateurs tels que SUM() et COUNT()

Les agrégateurs résument les lignes en une seule valeur. Les fonctions SUM() et COUNT() sont des
exemples d'agrégateurs. Les types d'agrégateurs qui seront disponibles pour vous dépendront du
dialecte SQL utilisé par votre entreprise. Mais les agrégateurs les plus couramment utilisés tels que
SUM(), COUNT(), MAX() et MIN() sont disponibles dans tous les dialectes SQL, même s'il existe de
légères différences. Il est facile de vérifier comment les agrégateurs sont formatés pour le dialecte
avec lequel vous travaillez. Il existe de nombreuses ressources disponibles en ligne. Il suffit d'ouvrir
votre moteur de recherche préféré et de rechercher la fonction d'agrégation que vous souhaitez
utiliser et votre dialecte SQL. Par exemple, recherchez « Fonction SUM dans SQL Server ». Les
agrégateurs fonctionnent tous de la même manière, alors passons en revue SUM() et COUNT(). La
fonction SUM() calcule la somme de la colonne que vous placez entre les parenthèses. La fonction
COUNT() compte le nombre d'entrées dans la colonne que vous placez entre parenthèses. Par
exemple, disons que vous avez un tableau des achats avec une liste de personnes et le nombre de
tickets de cinéma qu'elles ont achetés.

Le tableau des achats :

name tickets

Rachel DeSantos 3

Sujin Lee 2

Najil Okoro 2

John Anderson 1

Requête :

SELECT
SUM(tickets) AS total_tickets,
COUNT(tickets) AS number_of_purchases
FROM
purchases

Résultat :

total_tickets number_of_purchase
s

8 4
Vous pouvez également ajouter une clause DISTINCT à l'intérieur de la fonction. Cela fonctionnera
pour la plupart des dialectes SQL, mais il est toujours utile de vérifier et de confirmer que la fonction
fonctionne avec le dialecte utilisé par votre entreprise. L'ajout d'une clause DISTINCT dans votre
fonction SUM() ou COUNT() vous permet d'effectuer une agrégation uniquement sur chaque valeur
distincte du champ. Découvrez-le dans l’exemple ci-dessous :

SELECT
SUM(tickets) AS total_tickets,
SUM(DISTINCT tickets) AS total_distinct_tickets,
COUNT(tickets) AS number_of_purchases,
COUNT(DISTINCT tickets) AS
number_of_distinct_purchases
FROM
purchases

Résultat :

total_tickets total_distinct_tickets number_of_purchases number_of_distinct_

purchases

8 6 4 3

Vous remarquerez peut-être que les résultats contiennent des chiffres plus petits pour les colonnes
contenant DISTINCT. En effet, DISTINCT indique à SQL d'agréger uniquement les valeurs uniques.
Afin de mieux le comprendre, consultez la deuxième colonne total_distinct_tickets qui montre comment
la fonction DISTINCT peut être utilisée avec la fonction SUM(). Mais, dans cet exemple, il n'est pas
vraiment utile de faire une somme des valeurs distinctes. Vous n'utiliserez probablement jamais
DISTINCT avec les fonctions SUM(). Vous utiliserez plutôt DISTINCT avec les fonctions COUNT() car
cette clause est utile pour identifier les cas uniques.

Utiliser GROUP BY avec des agrégateurs

Précédemment, lorsque vous avez appris à utiliser SUM() et COUNT() avec des achats de tickets de
cinéma, vous avez résumé les données afin d’obtenir le nombre total de tickets achetés et le nombre
total d’achats effectués avec SUM() et COUNT(). Lorsque vous utilisez des fonctions d'agrégation telles
que SUM() et COUNT() avec une clause GROUP BY, les groupes sont résumés en tranches spécifiées
par la clause GROUP BY.

Par exemple, supposons que votre tableau des achats ressemble à celui présenté ci-dessous, dans
lequel la transaction de chaque personne concerne une occasion particulière. Vous pourriez vouloir
utiliser une clause GROUP BY si vous souhaitiez obtenir le nombre total de tickets vendus et le
nombre total d'achats effectués par type d'occasion. Vous remarquerez que si vous voulez agréger
par quelque chose (par exemple l'occasion), vous pouvez utiliser la clause GROUP BY. De cette
manière, SQL est assez intuitif.
Le nouveau tableau des achats :

occasion name tickets

fun Rachel DeSantos 5

date Sujin Lee 2

date Najil Okoro 2

fun John Anderson 3

Requête :
SELECT
occasion,
SUM(tickets) AS total_tickets,
COUNT(tickets) AS number_of_purchases
FROM
purchases
GROUP BY
occasion

Résultats :

occasion total_tickets number_of_purchases

fun 8 2

date 4 2

Génial ! Vous savez maintenant comment utiliser la clause GROUP BY et quand l'utiliser. Voici une
autre chose intéressante à savoir : vous pouvez utiliser le numéro de la colonne dans la clause GROUP
BY afin de spécifier ce que vous voulez regrouper au lieu d'utiliser les noms de colonnes. Dans le
dernier exemple, vous vouliez regrouper par occasion. Occasion est la première colonne écrite dans la
requête SQL. Cela signifie qu'il est possible d'écrire GROUP BY 1 au lieu de GROUP BY occasion. Si
l'occasion était la deuxième colonne de la clause SELECT, vous écririez alors GROUP BY 2. Voir ci-
dessous :

Requête :
SELECT
occasion,
SUM(tickets) AS total_tickets,
COUNT(tickets) AS number_of_purchases
FROM
purchases
GROUP BY
occasion
Est la même chose que :
SELECT
occasion,
SUM(tickets) AS total_tickets,
COUNT(tickets) AS number_of_purchases
FROM
purchases
GROUP BY
1

Connaître ce raccourci peut vous faire gagner du temps lors de la rédaction de vos requêtes SQL et
lorsque vous effectuez des regroupements sur plusieurs champs. Dans ce cas, il suffit de les séparer par
des virgules (par exemple GROUP BY 1, 2, 3, 4).

Quand utiliser HAVING

La clause HAVING est similaire à la clause WHERE puisqu'elle filtre les données en fonction de certaines
conditions. Mais ces clauses sont utilisées dans des situations différentes. La clause WHERE est
utilisée afin de créer des filtres sur votre tableau, par exemple un filtre pour certaines plages de
dates ou certains pays. La clause HAVING est utilisée afin de créer des filtres sur vos agrégations
et elle doit être associée à une clause GROUP BY.

Le tableau des
achats :

occasion name tickets

fun Rachel DeSantos 5

date Sujin Lee 2

date Najil Okoro 2

fun John Anderson 3

Dans cet exemple, vous remarquerez que vous pouvez superposer la clause HAVING si vous souhaitez
déterminer des limites à votre agrégation, ou à la somme et au nombre dans ce cas :
Requête :

SELECT
occasion,
SUM(tickets) AS total_tickets,
COUNT(tickets) AS number_of_purchases
FROM
purchases
GROUP BY
occasion
HAVING
SUM(tickets) > 5

Résultats :

occasion total_tickets number_of_purchases

fun 8 2

Il est important de noter que vos résultats ne contiennent plus l'occasion "date". C'est parce que votre
clause HAVING filtre les sommes qui sont supérieures à 5. L'occasion "date" n'avait que 4 tickets au
total, ce qui est inférieur à 5, donc l'occasion "date" n'apparaît pas dans vos résultats.

Excellent travail ! Vous savez maintenant comment et quand utiliser la clause HAVING. En tant
qu'analyste de données, vous utiliserez de nombreuses clauses WHERE et seulement quelques clauses
HAVING. Cela est dû au cas d'utilisation commerciale, mais aussi aux ressources, tout comme INNER
JOIN par rapport à INNER JOIN. LEFT JOIN. Si votre requête contient une clause HAVING, elle sera plus
longue à exécuter et consommera plus de ressources car SQL doit filtrer après avoir exécuté les calculs
SUM() et COUNT(). C'est donc une bonne idée d'essayer de minimiser l'utilisation de la clause HAVING
dans la mesure du possible. Mais, si vous avez besoin d'utiliser HAVING, essayez d'utiliser des tableaux
temporaires.

Utiliser ORDER BY pour organiser vos résultats

La clause ORDER BY vous aide à organiser vos résultats. Elle se place à la fin de la requête SQL et c'est
la toute dernière clause à utiliser, sauf si vous avez une clause LIMIT.

Une version légèrement modifiée du tableau d'achat :

name tickets

Rachel DeSantos 3

Sujin Lee 5

Najil Okoro 2

John Anderson 4
Disons que nous voulons que toutes les personnes figurant dans ce tableau soient organisées par le
nombre de tickets qu'elles ont achetés, du plus grand au plus petit, ou dans l’ordre décroissant.

SELECT
name,
tickets
FROM
purchases
ORDER BY
tickets DESC

Résultat :

name tickets

Sujin Lee 5

John Anderson 4

Rachel DeSantos 3

Najil Okoro 2

Si vous voulez afficher en premier la personne qui a le moins de tickets, vous devez classer vos
résultats dans l’ordre ASCendant. Pour cela, dans SQL, vous pouvez soit utiliser ASC, soit laisser
le champ vide, car SQL trie par défaut les colonnes dans l’ordre ASCendant. Mais la meilleure
pratique consiste à écrire ASC ou DESC afin que cette clause soit claire pour tous ceux qui lisent
votre requête.

Quand utiliser LIMIT

La clause LIMIT est utile lorsque vous ne souhaitez travailler qu'avec un nombre restreint de lignes. Elle
est généralement utilisée dans deux situations.

Dans la première situation, disons que vous voulez le nombre X de cas les plus élevés. Dans l'exemple
des tickets de cinéma, disons que vous ne voulez que les trois plus gros achats. Vous pouvez utiliser une
clause LIMIT comme ci-dessous.

Requête :

SELECT
name,
tickets
FROM
purchases
ORDER BY
tickets DESC
LIMIT 3 --top 3 results only
Résultat :

name tickets

Sujin Lee 5

John Anderson 4

Rachel DeSantos 3

Dans la deuxième situation, disons que vous voulez travailler avec l'ensemble de vos données avant
de rédiger votre requête. Dans ce cas, vous utiliserez une clause LIMIT afin de ne pas gaspiller des
ressources en extrayant chaque ligne.

Requête :
SELECT
name,
tickets
FROM
purchases
ORDER BY
tickets DESC
LIMIT 20 --top 20 results only

Résultat :

name tickets

Rachel DeSantos 3

Sujin Lee 5

Najil Okoro 2

John Anderson 4

Vous avez peut-être remarqué que vous n'avez que quatre lignes de données dans vos résultats, même si
vous avez déterminé une limite.
20. C'est parce que le tableau des achats ne contient que quatre lignes de données. La clause LIMIT
indique le nombre maximal de lignes à afficher. Si le tableau des achats contient un million de lignes,
seules 20 lignes seront affichées. Mais, le tableau des achats contenant moins de 20 lignes, toutes les
données sont affichées.

Expressions conditionnelles telles que CASE, IF et COALESCE()

Les expressions conditionnelles comme les instructions CASE et la fonction COALESCE() sont
utilisées lorsque vous souhaitez modifier la présentation de vos résultats. Bien que vous définissiez des
conditions dans des expressions conditionnelles, celles-ci diffèrent du type de conditions que vous mettez
dans une clause WHERE. Les conditions mises dans les clauses WHERE s'appliquent à l'ensemble de la
requête, tandis que les expressions conditionnelles ne s'appliquent qu'à un champ particulier. En outre,
vous pouvez modifier la présentation de vos résultats à l'aide d'expressions conditionnelles, ce que vous
ne pouvez pas faire avec les instructions WHERE. Voyons les trois expressions conditionnelles les plus
courantes : CASE, IF et COALESCE().

Instructions CASE
Les instructions CASE sont le plus souvent utilisées en tant qu’étiquettes dans votre jeu de données.
Vous pouvez utiliser les instructions CASE pour étiqueter les lignes qui répondent à une certaine
condition, par exemple X et les lignes qui répondent à une autre condition, par exemple Y. C'est pourquoi
elles sont souvent utilisées avec les fonctions d'agrégation lorsque vous souhaitez regrouper des
éléments par catégories. Voici un exemple utilisant un tableau des films qui passent au cinéma local :

Le tableau du cinéma :

genre movie_title

horror Silence of the Lambs

comedy Jumanji

family Frozen 2

documentary 13th

Disons que vous voulez regrouper ces films en deux catégories : ceux que vous regarderez et ceux
que vous ne regarderez pas et que vous voulez compter le nombre de films qui appartiennent à
chaque catégorie. Votre requête serait :
SELECT
CASE
WHEN genre = ‘horror’ THEN ‘will not watch’
ELSE ‘will watch’
END AS watch_category, --creating your own category
COUNT(movie_title) AS number_of_movies
FROM
MovieTheater
GROUP BY
1 --lorsque vous regroupez par CASE, utilisez les numéros de
position ou saisissez l’instruction CASE entière ici

Résultats :

watch_category number_of_movies

Ne regardera pas 1

Regardera 3

Vous avez peut-être remarqué que vous avez ajouté vos propres étiquettes au jeu de données, ce
que vous pouvez faire avec les instructions CASE. Mais gardez à l'esprit que cette fonction n'est pas
présente dans tous les dialectes SQL, dont BigQuery. Si vous souhaitez en savoir plus, consultez la
documentation relative à COUNT() ou SUM() pour votre dialecte SQL particulier et vérifiez comment
les instructions CASE peuvent être utilisées.

Il existe également une autre façon d'utiliser les instructions CASE dans BigQuery (là encore, cela
peut ne pas s'appliquer à tous les dialectes SQL). Si vos conditions sont des correspondances,
comme dans l'exemple ci-dessus, vous pouvez écrire votre instruction CASE de la manière suivante
(comparez les lignes 2 et 3) :

SELECT
CASE genre
WHEN ‘horror’ THEN ‘will not watch’ ELSE
‘will watch’
END AS watch_category
COUNT(movie_title) AS number_of_movies
FROM
MovieTheater
GROUP BY
1

Cette méthode donne les mêmes résultats, mais elle n'est pas recommandée car elle est limitée aux
conditions de correspondance (par exemple, genre = "horror"). En comparaison, la version
précédente avec WHEN genre = "horror" est flexible et peut accepter d'autres types de conditions,
tels que supérieur à (>), inférieur à (<), pas égal à (<> ou !=), etc.

Instructions IF
Ensuite, il y a les instructions IF. Les instructions IF sont similaires aux instructions CASE, mais
elles ont une différence essentielle : Les instructions CASE peuvent tenir compte de plusieurs
conditions, alors que les instructions IF ne le peuvent pas. Dans l'exemple ci-dessus, vous n'aviez
qu'une seule condition (par exemple WHEN genre = "horror"), vous auriez donc pu utiliser une
instruction IF telle que :

SELECT
IF(genre=’horror’, ‘will not watch’, ‘will watch’) AS
watch_category,
COUNT(movie_title) AS number_of_movies
FROM
MovieTheater
GROUP BY
1
Mais, si vous avez plusieurs conditions, vous devrez utiliser une instruction CASE telle que :

SELECT
CASE
WHEN genre = ‘horror’ THEN ‘will not watch’
WHEN genre = ‘documentary’ THEN ‘will watch
alone’
ELSE ‘watch with others’
END AS watch_category,
COUNT (movie_title) AS number_of_movies
FROM
MovieTheater
GROUP BY
1

Résultats :

watch_category number_of_movies

Ne regardera pas 1

Regardera seul 1

Regardera avec 2
d'autres personnes

Fonction COALESCE()
Enfin, il y a la fonction COALESCE(). Cette fonction est utilisée pour renvoyer la première expression non
null dans l'ordre spécifié dans la fonction. Elle est utile lorsque vos données sont réparties sur plusieurs
colonnes. Par exemple, disons que vous disposez d'un tableau de films comme lignes, de colonnes avec
les mois et de valeurs telles que 1 si le film est sorti au cours de ce mois ou null si ça n’est pas le cas.
Reportez-vous au tableau MovieLaunches ci-dessous :

movie_title Jan_2030 Feb_2030 Mar_2030

Avengers X 1 null null

Frozen V null 1 null

Lion King IV null null null

Si vous voulez savoir si ces films sont sortis entre janvier et mars 2030, vous pouvez utiliser
COALESCE. Par exemple :
SELECT
movie_title,
COALESCE(Jan_2030, Feb_2030, Mar_2030) AS
launched_indicator
FROM
MovieLaunches

Résultats :

movie_title launched_indicator

Avengers X 1

Frozen V 1

Lion King IV null

Vous remarquerez que deux des trois films ont des valeurs non null dans les champs spécifiés (Jan_2030,
Feb_2030, Mar_2030). Cet exemple montre comment fonctionne la fonction COALESCE. Elle recherchera
chaque colonne que vous spécifiez dans la fonction et elle essaiera de renvoyer une valeur non null si elle
en trouve une.

Sur le lieu de travail, COALESCE est souvent utilisé afin de s'assurer que les champs ne contiennent
pas de valeur null. Ainsi, une instruction COALESCE pourrait être : COALESCE(try_this_field,
then_this_field, 0) afin d’indiquer à SQL de vérifier les deux premiers champs dans l'ordre pour trouver
une valeur non null. S'il n'en existe pas dans ces champs, attribuez un zéro à la place de la valeur null.
Dans BigQuery, cela revient à utiliser la fonction IFNULL() (plus d'informations à ce sujet ici). D'autres
dialectes SQL peuvent ne pas avoir la fonction IFNULL() et dans ce cas, COALESCE() est alors utilisée
à la place.

Créer et supprimer des tableaux

Dans SQL, les données sont stockées dans des tableaux. Ce guide se réfère à de petits tableaux tels que
les tableaux des achats, MovieLaunches et MovieTheater. Ce sont les tableaux qui existent déjà parce que
vous ne les avez pas créés.

Créer des tableaux

La situation idéale pour créer un tableau est que les trois conditions suivantes soient remplies :
1. Requête complexe contenant plusieurs instructions JOIN
2. Le résultat est un tableau
3. Vous devez exécuter la requête fréquemment ou régulièrement

Si ces conditions sont remplies, la création d'un tableau de création de rapports est une bonne
idée. Mais il est préférable de vérifier avec votre responsable ou vos collègues avant de le faire,
au cas où vous auriez besoin d'accéder à des autorisations pour créer un tableau de création de
rapports.
La syntaxe de création des tableaux change en fonction du dialecte SQL et de la plateforme SQL que
vous utilisez. Nous verrons ici comment créer des tableaux dans BigQuery, mais si votre entreprise
utilise un autre dialecte SQL, il est conseillé de rechercher en ligne comment créer des tableaux dans ce
dialecte SQL (par exemple, dans « Créer des tableaux en PostgreSQL »). Ou mieux encore, demandez
de l'aide à votre responsable ou à un collègue.

En règle générale, lorsque vous créez des tableaux, vous devez vous assurer que le même tableau
n'existe pas déjà. En effet, si vous essayez de créer un tableau qui existe déjà, la requête renverra
une erreur.
La vérification des tableaux existants diffère selon les dialectes SQL, mais il est toujours utile de le vérifier
afin
d’éviter des erreurs inutiles dans votre travail.

La façon de vérifier la présence de tableaux préexistants dans BigQuery est la suivante :

CREATE TABLE IF NOT EXISTS [Link] AS

SELECT
friend,
color,
movie
FROM
Favorite_Colors AS c
INNER JOIN
Favorite_Movies AS m ON [Link] = [Link]

Vous avez déjà créé un tableau FavoriteColorAndMovie ! Vous pouvez vous référer à ce tableau unique
afin de trouver la couleur préférée et/ou le film préféré de chaque ami sans avoir à joindre les deux
tableaux distincts, Favorite_Colors et Favorite_Movies, à chaque fois.

La méthode CREATE TABLE IF NOT EXISTS est la meilleure si les tableaux de votre requête (par
exemple, Favorite_Colors et Favorite_Movies) ne sont pas continuellement mis à jour. La commande
CREATE TABLE IF NOT EXISTS ne fera rien si le tableau existe déjà, car il ne sera pas mis à jour. Donc,
si les tableaux sources sont continuellement mis à jour (par exemple, de nouveaux amis sont
continuellement ajoutés avec leurs couleurs et films préférés), il est préférable d'opter pour une autre
méthode pour créer des tableaux.

Cette autre méthode pour créer des tableaux est la méthode CREATE OR REPLACE TABLE. Voici
comment elle fonctionne :
CREATE OR REPLACE TABLE [Link]
AS
SELECT
friend,
color,
movie
FROM
Favorite_Colors AS c
INNER JOIN
 Favorite_Movies AS m ON [Link] = [Link]

Vous pouvez remarquer que la seule différence entre les deux façons de créer des tableaux est la
première ligne de la requête. Elle indique à SQL ce qu'il doit faire si le tableau existe déjà.
CREATE TABLE IF NOT EXISTS ne créera un tableau que s’il n'existe pas déjà. S'il en existe un,
la requête sera exécutée mais ne fera rien. Il s'agit d'un dispositif de sécurité qui permet d'éviter
d'écraser accidentellement un tableau potentiellement important. Sinon, si vous devez écraser un
tableau, vous pouvez utiliser CREATE OR REPLACE TABLE.

En résumé, vous utiliserez CREATE TABLE IF NOT EXISTS si vous créez un tableau statique qui n'a pas
besoin d'être mis à jour. Si votre tableau doit être mis à jour en permanence, vous utiliserez plutôt
CREATE OR REPLACE TABLE.

Supprimer des tableaux

Parlons maintenant de la suppression de tableaux. Cela se produit rarement, mais il est
important de le savoir car, une fois les tableaux supprimés, les données qu'ils contiennent
peuvent être perdues. Et, les données appartenant à l'entreprise pour laquelle vous travaillez, la
suppression d'un tableau peut signifier que vous vous débarrassez de quelque chose qui ne vous
appartient pas.

Pensez à la façon dont vous traiteriez un compte de médias sociaux qui ne vous appartiendrait pas.
Par exemple, si votre entreprise vous a donné accès à son compte. Vous pouvez regarder les
publications et peut-être (avec une permission) créer votre propre publication pour elle, mais vous ne
supprimeriez pas un message de média social car il s'agit du compte du propriétaire, pas du vôtre.

Si vous envisagez d'appuyer sur le bouton de suppression d'un tableau que vous n'avez pas créé,
assurez-vous de vérifier les raisons pour lesquelles vous appuyez sur le bouton de suppression et
vérifiez auprès de votre responsable, au cas où.

Mais si vous avez besoin de supprimer un tableau, surtout s'il s'agit d'un tableau que vous avez créé
et dont vous n'avez plus besoin, vous pouvez supprimer un tableau dans BigQuery en utilisant cette
requête :

DROP TABLE IF EXISTS [Link]

DROP TABLE indique à SQL de supprimer le tableau et la partie IF EXISTS permet de s'assurer que
vous n'obtenez pas d'erreur si le tableau n'existe pas. Il s'agit d'un dispositif de sécurité, ainsi si le tableau
existe, il sera abandonné. Si le tableau n'existe pas et que vous exécutez cette requête, rien ne se
passera. Donc, dans tous les cas, la sécurité intégrée joue en votre faveur. La meilleure pratique consiste
à ajouter l’instruction IF EXISTS.

Tableaux temporaires
Jusqu'à présent, vous avez appris comment créer des tableaux et dans quelles circonstances
vous devez les créer. N'hésitez pas à consulter la section ci-dessus si vous avez besoin de vous
rafraîchir la mémoire. Les tableaux que vous créez avec la méthode CREATE TABLE IF NOT
EXISTS ou la méthode CREATE OR REPLACE TABLE sont des tableaux permanents. Ils
peuvent être partagés et vus par d'autres personnes et on peut y accéder ultérieurement.
Mais, il peut y avoir des situations dans lesquelles vous n'avez pas besoin de créer de tableaux
permanents. N'oubliez pas que le stockage des données dans SQL coûte de l'argent et des ressources
à l'entreprise. Si vous n'avez pas besoin d'un tableau permanent, vous pouvez créer des tableaux
temporaires à la place. Les tableaux temporaires n'existent que pendant votre session (ou jusqu'à
24 heures selon votre plateforme SQL) et ils ne sont ni partageables ni consultables par d'autres
personnes. Les tableaux temporaires n'existent que pour vous pendant votre session. Considérez les
tableaux temporaires comme un bloc-notes dans lequel vous pouvez griffonner vos calculs avant de
rédiger votre réponse finale.

Commençons par expliquer dans quelles circonstances vous devriez créer un tableau permanent ou un
tableau temporaire.

Voici les trois conditions pour lesquelles vous devriez créer un tableau permanent. Les trois
conditions doivent être remplies.
1. Requête complexe contenant plusieurs instructions JOIN
2. Le résultat est un tableau
3. Vous devez exécuter la requête fréquemment ou régulièrement

Par ailleurs, les tableaux temporaires sont utilisés afin de décomposer des requêtes complexes en
plus petits incréments. Ces requêtes complexes peuvent contenir plusieurs instructions JOIN, mais ce
n’est pas nécessairement le cas. Vous pourriez vouloir utiliser des tableaux temporaires si l'une ou
plusieurs des conditions suivantes s'appliquent :
● Requête qui s'exécute lentement avec de multiples instructions JOIN et WHERE
● Exécution lente d'une requête contenant GROUP BY et HAVING
● Requêtes imbriquées (c'est-à-dire une requête dans une requête)
● Si vous avez besoin de faire un calcul sur un autre calcul (par exemple prendre la somme
par jour puis faire la moyenne des sommes quotidiennes)

Si l'une des conditions ci-dessus est remplie, l'utilisation d'un tableau temporaire peut accélérer votre
requête, ce qui vous facilitera la rédaction de la requête, ainsi que le dépannage de votre requête si
quelque chose ne va pas.

Voici comment créer un tableau temporaire :

CREATE TEMP TABLE ExampleTable
AS
SELECT
colors
FROM
Favorite_Colors
Maintenant, revenons au tableau permanent que vous avez créée auparavant :
CREATE TABLE IF NOT EXISTS [Link] AS
SELECT
friend,
color,
movie
FROM
Favorite_Colors AS c
INNER JOIN
Favorite_Movies AS m ON [Link] = [Link]

Cette requête fonctionne pour un tableau permanent car les trois conditions que nous avons
mentionnées précédemment sont remplies. Mais, pour les tableaux temporaires, cette requête n'est
pas une bonne idée. Vous travaillez avec des instructions JOIN multiples mais il n'y a pas d'instruction
WHERE et la requête s'exécute très rapidement car les tableaux Favorite_Colors et Favorite_Movies
sont relativement petits (<100k lignes).

Considérons un autre scénario dans lequel vous pourriez vouloir utiliser des tableaux temporaires.
Précédemment, vous avez appris les notions de GROUP BY et HAVING. Si votre requête contient les
deux clauses, comme celles ci-dessous, vous pourriez utiliser des tableaux temporaires si votre
requête s'exécute lentement.

Requête de tableau temporaire (si votre requête s'exécute lentement) :

SELECT
occasion,
SUM(tickets) AS total_tickets,
COUNT(tickets) AS number_of_purchases
FROM
purchases
GROUP BY
occasion
HAVING
SUM(tickets) > 5

Dans la requête ci-dessus, SQL doit effectuer trois actions. Tout d'abord, il regroupera votre tableau par
occasion. Ensuite, il prendra le SUM() et le COUNT() de la colonne des tickets. Troisièmement, il
n’affichera que les occasions dont le SUM() des tickets est supérieur à cinq. Si le tableau des achats était
beaucoup plus grand (plus d'un million de lignes) et que vous aviez également des instructions JOIN
dans ce tableau, votre requête s'exécuterait très probablement lentement. Mais vous pouvez l’éviter en
utilisant la clause HAVING et accélérer votre requête en la décomposant en deux étapes à l'aide de
tableaux temporaires.
Tout d'abord, vous pouvez effectuer les agrégations GROUP BY :
CREATE TEMP TABLE TicketsByOccasion AS
SELECT
occasion,
SUM(tickets) AS total_tickets,
COUNT(tickets) AS number_of_purchases
FROM
purchases
GROUP BY
occasion;

Ensuite, vous pouvez faire la limitation HAVING en tant que condition WHERE :
SELECT
occasion,
total_tickets,
number_of_purchases
FROM
TicketsByOccasion
WHER
total_tickets > 5
E

Il y a trois éléments clés à noter dans ce cas :

1. Si vous exécutez deux requêtes en même temps, ce que vous devez faire avec les
tableaux temporaires (disponibles uniquement pendant cette session), vous avez besoin
d'un point-virgule pour séparer chaque requête.
2. La première requête est celle avec laquelle vous avez créé le tableau temporaire. La deuxième
requête se réfère à ce
tableau temporaire et à ses champs. C'est pourquoi vous pouvez accéder à la somme des
tickets en tant que total_tickets dans la deuxième requête.
3. Lorsque vous créez des noms de tableaux, n'utilisez pas d'espaces, sinon la requête renverra
une erreur. La meilleure pratique consiste à utiliser la capitalisation CamelCase pour nommer le
tableau que vous créez. La capitalisation CamelCase signifie que vous mettez une majuscule
au début de chaque mot, sans aucun espace entre, comme la bosse d'un chameau. Le tableau
TicketsByOccasion utilise donc la capitalisation CamelCase.

En conclusion, vous n'êtes pas obligé d'utiliser des tableaux temporaires, mais ils peuvent être un outil très
utile pour décomposer des requêtes complexes ou compliquées en étapes plus petites et plus faciles à
gérer.
Conclusion
Ce guide couvre un grand nombre de concepts, mais vous pourrez y revenir à plusieurs reprises
lorsque vous continuerez à rédiger des requêtes SQL par vous-même. Comme vous l'avez appris tout
au long de ce cours, la pratique est une partie importante du processus d'apprentissage et plus vous
vous exercerez à travailler en SQL, plus vous ferez de nouvelles découvertes. Vous pouvez
sauvegarder ce guide afin de pouvoir le consulter et vous référer à ces fonctions et concepts si
nécessaire.