Bruno:
Tout le monde connaît le SQL, ou du moins tout le monde pense connaître le SQL. On a tous fait des selects étoiles from un jour, on a tous juré sur des jointures qui ne fonctionnent pas vraiment, et on a tous fini par dire c'est la base de données qui rame. Mais SQL, ce n'est pas qu'un langage de requête, c'est un langage déclaratif, riche, puissant, et très souvent, voire même trop souvent, sous-estimé. Mais alors, pourquoi SQL paraît-il si simple et pourtant si mal compris ? Faut-il vraiment apprendre à écrire du SQL propre ? Et surtout, est-ce que le SQL peut encore être sexy aujourd'hui ? Pour répondre à ces questions bien ordonnées, je ne reçois pas Flipper le dauphin, mais il s'y connaît en requête qui grince. Cédric, bonjour.
Cedric:
Bonjour.
Bruno:
Alors Cédric, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Cedric:
Cédric Miachon, Head of Data chez les Furets. J'ai un doctorat en base de données en 2006 et je travaille chez l'EFER depuis 15 ans. Et j'ai aussi enseigné la base de données. Peut-être qu'on en reviendra sur ce point pendant longtemps en fac ou en école.
Bruno:
Donc la base de données, c'est ton domaine de prédilection. C'est le sujet qui t'a attrapé quand t'es arrivé en école ou dès le plus jeune âge ?
Cedric:
En cours de chemin, oui. Et puis je voulais racheter que je trouve effectivement le SQL sexy.
Bruno:
OK. alors c'est quoi justement dans le SQL que tu trouves si sexy parce que pour la majesté des devs nous on fait des requêtes il y en a même maintenant qui font même plus de requêtes SQL c'est à dire qu'ils passent par un ORM, qui construit la requête, qui prépare le statement pour eux qu'est-ce que toi tu trouves de sexy dans le SQL.
Cedric:
Comme tu disais en introduction c'est l'aspect déclaratif en gros, on dit ce qu'on c'est un changement de paradigme dans les langages de programmation, on connaît tous certains paradigmes, on a l'objet, le fonctionnel qui commence à arriver un peu. Ou à revenir. Ou arriver, ça dépend. Moi, je viens du basic, donc c'est très procédural et impératif, ce genre de choses. Et on a le déclaratif. Qu'est-ce qu'on entend par déclaratif ? C'est qu'on dit ce qu'on veut. En gros, c'est assez simplifié de l'SQL. On a du select from where donc je pense que vous connaissez tout ça, et on dit select, qu'est-ce que je veux quelles sont les colonnes qui m'intéressent le from, à partir de quel ensemble de données et le where, quelles conditions je veux y appliquer quel filtrage, et voilà, on ne s'intéresse pas à l'algorithme aux algorithmes sous-jacents derrière, ça c'est le moteur, de l'AGBDR ou autre qui va aller s'occuper de faire, trouver le meilleur algorithme pour rejoindre ces données.
Bruno:
Ok, très clair. Et donc, ce qui est toujours aussi surprenant, c'est que tu nous as expliqué ce select fromware qui est effectivement le B à bas, on va dire, du SQL et qui est aussi l'usage principal qui en effet, alors on peut rajouter quelques jointures, où effectivement il y a quelques devs qui se frottent un peu à ça avec plus ou moins de succès, mais ce qui est ignoré par beaucoup de développeurs, c'est que le SQL est un langage Turing Complete, ce qui veut dire que techniquement, on peut effectivement programmer tout en SQL. Je vais poser une question très bête. Dans quelle mesure est-ce que tu peux exploiter le côté Turing Complice de SQL ? Est-ce qu'au final, il faut être sur un niveau d'usage vraiment ultra-experienced, ou au final, très vite, toi, tu rentres dans ce genre de sujet ?
Cedric:
Alors ça, c'est mon avis. Oui, le SQL depuis l'année et Turing Complice, c'était pas l'origine de la... pas le cas à la base. Le SQL était prévu par Edward Code comme étant nom de Thuring Complets. Il est devenu Thuring Complets, c'est-à-dire que tu peux y appliquer la récursivité et puis dans certains cas, tu peux rêver à faire des algos sympas avec les CTE. Dans mon cas, en fait, il n'y a qu'une seule fois où on a eu besoin de se servir de la récursivité sur un cas métier un peu complexe où il a fallu revenir faire du chaînage, franchement qu'il n'y a pas de limite, donc on sait pas où s'arrêter, donc c'était un seul use case en 15 ans de boîte sur lequel on a eu besoin de faire des requêtes récursives. Je vous déconseille de faire de la récursivité et d'appliquer cette notion de fonction dans SQL. C'est pas fait pour mon avis. Je pense qu'il faut vraiment le voir comme quelque chose de déclaratif, simplifié, ne pas faire plus que nécessaire chaque outil, chaque usage et si on veut commencer à traiter des aspects de fonction, on a besoin de chercher des points fixes, l'intérêt de la nature et de complétude. Il vaut mieux utiliser d'autres langages qui sont prévus pour ça, l'objet, le fonctionnel ou autre. Je pense que vous voyez le SQL comme la récupération de données, la manipulation et la transformation de données. Et après, si on a besoin d'aller sur... Plus complexe, on a d'autres langages.
Bruno:
Et est-ce que du coup sur le fait que toi, en 17 ans de carrière, t'aies eu besoin d'utiliser qu'une seule fois, est-ce que ça veut dire que même toi, le jour où t'en as eu besoin, t'as été obligé de te référer quand même à la doc, parce que t'étais quand même un truc où t'étais pas...
Cedric:
Ah ouais, c'était compliqué. Pardon, c'était compliqué, ouais. C'était aussi intéressant, on apprend tous les jours, c'est cool. Et puis ça a marché, on s'est un peu cassés les dents, parce que j'étais pas tout seul. On s'est un peu cassés les dents là-dessus, pour faire une enquête assez jolie. Mais c'était plus un exercice de pensée, un exercice théorique. On s'est dit, allez, dans ce cadre-là, ça va être sympa de faire de 4 récursives, on va apprendre.
Bruno:
Vous auriez pu faire le choix à l'époque de vous dire, allez, on va passer en Java pour faire le traitement.
Cedric:
Ça va être plus compliqué, parce qu'il aurait fallu revenir en arrière. On va y la donner, la retransférer. On va le faire là, dans ce cadre particulier.
Bruno:
Dans le SQL là tu nous as parlé du select fromware qui sont effectivement comme on le disait la base du SQL il y a une structure quand même qui est extrêmement, on va pas aller beaucoup plus loin il y a d'autres parties dans les, possibilités il y a la jointure il y a le having il y a encore d'autres choses c'est quoi tous les blocs possibles et imaginables d'une requête SQL ?
Cedric:
Il y a beaucoup de choses. On parlait du site-frameware, c'est la base. Après, tu vas voir le order by, tu vas voir le group by, donc là on commence au niveau un peu avancé. On peut le voir comme du TCD, le tableau croisé dynamique en Excel, groupé par dimensions et tu vas appliquer une fonction d'agrégat. La fonction d'agrégat, c'est un compte étoile, c'est un compte distinct c'est un sum, moyenne un min max qu'est-ce que j'oublie il y en a quelques-unes autres, et donc ça c'est le group buy donc le part en gros c'est je veux avoir je sais pas la taille moyenne par genre et donc je fais un group buy au genre et average la taille d'une personne donc là j'ai ma roquette qui fonctionne donc le group buy c'est vraiment le niveau un peu avancé déjà, oui c'est facile à maîtriser mais surtout que ce que tu décris c'est le group buy aussi avec une fonction d'agrégat oui je pense qu'il y a beaucoup de gens qui utilisent un group buy sur un champ ouais j'espère j'espère pas.
Bruno:
Bah je pense que.
Cedric:
Tu peux l'utiliser uniquement dans un cas particulier pour faire du distinct ouais, un group buy sans appliquer l'agrégat, ça va te faire un distinct. Le gros distinct, c'est que tu veux retirer tous les doublons aussi, donc faire un select distinct de tes colonnes, et donc, analytiquement, tu as retiré tes doublons. Tu vas avoir d'autres fonctions, alors tu as évoqué le having, mais ça s'applique après un group buy, si tu veux appliquer un filtre sur le résultat de ton agrégat. Ou tu peux le faire au-dessus en faisant une CTE, donc tu crées ta requête à part, tu la nommes, et tu vas y réappliquer après un filtre sur le résultat de ta requête. Tu peux le faire en naving ou tu peux le faire ailleurs, à un autre niveau. Tu as les jointures, c'est généralement la petite douleur au début. C'est le produit cartésien, c'est la multiplication de deux tables. Tu as la jointure avec une condition de jointure, c'est le produit cartésien où tu vas garder celle dont la condition de jointure match. C'est une colonne A à gauche, une colonne B, tu veux que la colonne A et B soient la même. Il faut uniquement te concentrer là-dessus. Et après tu vas avoir les semi-jointures qui sont aussi classiques donc les semi-jointures c'est la jointure à gauche la left join, la jointure à droite la right join c'est la même chose mais inversée et après t'en as encore plein d'autres la full outer join, un niveau très avancé mais déjà la left join est vachement pratique ça permet d'avoir les éléments de A. Quand tu fais un A left join B ça permet d'avoir dans A les éléments de B qui sont dans A, et garder tous les éléments de A si tu fais un left A join B tu n'auras que A et B qui matchent les deux c'est très simple je pense qu'il y en a je pense qu'il y en a qui vont hurler non c'est pas ça je l'explique très mal mais bon non.
Bruno:
Mais jusque là en tout cas pour le commun des mortels c'est clair.
Cedric:
Qu'est-ce que j'oublie et alors c'était intéressant parce que j'ai raccouté d'autres épisodes notamment l'épisode de Laetitia Auro numéro 61 et il y a un truc intéressant qu'elle disait c'est, les cours L'enseignement qui est fait en université, en école, sur le SQL était plutôt mal fait. Je l'ai rejoint pour l'avoir enseigné à peu près 10 ans, par une audience. Et il a cité notamment le fenêtrage, les Windows Functions. Ça, c'est quelque chose que moi, je ne connaissais pas. Je n'ai pas enseigné parce que je ne connaissais pas. Et que j'ai appris sur le tard, il y a une dizaine d'années. Alors que je pensais déjà avoir un bon niveau, j'ai fait une claque. Je trouve ça vachement bien. Une fois qu'on maîtrise ça, ça permet d'avoir des requêtes hyper claires, hyper synthétiques. C'est pour ça qu'on peut réduire des requêtes à peu de lignes. Parce qu'en gros, ta requête qui fait un groupe buy, je le simplifie, ça te tient en ligne dans un select. Je simplifie simplement. Au lieu d'avoir un groupe buy qui fait 10 lignes que tu vas avoir quelque part, en une ligne, tu as ton groupe buy. Et tu lis de manière très simple. Ça simplifie beaucoup tes requêtes et ça, c'est un niveau incroyable. Quand j'ai découvert ça, j'étais ravi.
Bruno:
C'est-à-dire quoi ? Tu crées des sous-requêtes que tu peux appeler dans une requête après l'arrière ou tu crées des fonctions ?
Cedric:
C'est vrai, c'est comme une fonction que tu vas appliquer. Tu peux le voir comme une fonction que tu vas appliquer dans ton select à partir de tes données. Et ça reste les mêmes fonctions d'agrégat sauf que là, tu peux avoir différentes. Oui c'est la même fonction ce qui est très utilisé en général c'est le run number ou le rank ou le run number où tu vas pouvoir trier et mettre un ordre et après tu vas y appliquer un filtrage tu gardes que le premier, ça simplifie vachement la lecture ok.
Bruno:
Donc on a dit le group by, le order, le having les windows functions il y a encore d'autres secrets cachés.
Cedric:
Après il y a les fonctions récursives j'aime pas.
Bruno:
C'est déconseillé moi.
Cedric:
Je déconseille après on peut le faire pour le plaisir et pour le fun c'est intéressant résoudre des problèmes connus comme étant compliqués c'est sympa.
Bruno:
Alors justement c'est que tu parlais de Laetitia tout à l'heure, je pense que tu connais l'advent of code tu sais il y a une espèce de calendrier de l'avant où t'as un problème à résoudre en code, chaque jour avant Noël, et je crois que c'est l'année dernière ou l'année précédente, je ne sais pas si Laetitia écoutera cet épisode, elle pourra confirmer ou affirmer, mais il y a une année où elle a décidé de faire tous les challenges en SQL. Donc ça montre la capacité de ce langage de faire beaucoup plus que ce que la majorité des devs imaginent.
Cedric:
J'ai regardé, c'est intéressant.
Bruno:
Il y a aussi un point qui est important. Tu as expliqué notamment que le having va s'exécuter après le group buy. Dans la notion de... Quand tu commences à gérer des performances de tes requêtes, parce que tu vois que il y a des choses qui sont plus ou moins longues, il faut aussi s'intéresser à l'ordre dans lequel sont exécutés les différents morceaux. Il y a toujours un truc, notamment j'ai un doute. Donc on le sait la différence entre un from et un join c'est que le from, tu as tous les éléments communs à tes deux tables là où le join te permet d'avoir les éléments qui sont dans A et dans B mais d'avoir quand même ceux qui sont dans A mais qui ne sont pas dans B c'est la semi-jointure à gauche, il y a une différence d'ordre d'exécution aussi, enfin tu vois comment ça s'exécute tout ça entre...
Cedric:
Dans un LGBDR donc système de gestion de base de données relationnelles en fait, il ne faut pas que tu t'en occupe, tu n'as pas à réfléchir à ça tu as l'optimisateur de requête qui va regarder derrière donc c'est un plan de requête il y a tout un tas de choses qui rentrent dans la partie BDA et, il ne faut pas que tu regardes il faut que tu saches moi je veux juste ma semi-jointure je veux des éléments de A qui ne sont pas dans B, après je dis ça je réponds bien ta question oui il y a plein de cas où ça marche pas où on comprend pas ça dure des plombes la requête elle est pas optimisée, et c'est là où tu commences à regarder autre chose donc si tu restes dans le système relationnel la question qui vient c'est les index, les jointures ça marche bien si t'as les bons index donc si on peut parler un peu en termes d'optimisation. En termes de complexité pardon normalement une jointure, si t'as les bons index en général ça s'exécute en, en nlogan ça reste quasi du linéaire c'est pas du quadratique donc ça devrait pas prendre trop de temps, donc si ça prend trop de temps c'est qu'il y a probablement pas les bons index, et là j'en ai vu des erreurs dans le passé, des gens qui ont pas forcément les bons réflexes, et là on revient au point de départ c'est que les bases de données sont pas forcément bien enseignées, j'ai vu une fois quelqu'un qui mettait un index sur chaque colonne donc ça n'avait pas de sens donc non il y a certaines logiques je me rappelle que justement pour, Titi Avro de parler de il faut se mettre en forme normale il y a les formes normales qui ont été introduites donc il faut que les bases données soient en troisième forme normale si t'es en base de données relationnelles les bases de données relationnelles c'est MySQL, Postgre, Oracle, le serveur, etc. Donc oui, il faut réfléchir à tout ça.
Bruno:
Ce qui est intéressant sur ce que tu dis, c'est que si je mets un index sur tous les champs de ma base, au final, mes requêtes vont être, chez des jointures, elles vont être toutes plus rapides à s'exécuter, mais chacun de mes inserts et de mes updates vont prendre un temps fou. C'est ça le problème majeur ou pourquoi il ne faut pas le faire ?
Cedric:
Les index, ça prend déjà de la place.
Bruno:
Mais ça, le stockage aujourd'hui.
Cedric:
C'est plus... mais ça prend quand même de la place. Pourquoi il ne faut pas le faire ? Parce que, après, il y a toujours des cases où ça pourrait être le cas, cette table n'allait à que deux colonnes peut-être. Non, parce que les index, en fait, il y a une question de répartie, d'activité. Si tu as une colonne qui a deux valeurs, par exemple, je parlais des genres tout à l'heure, si tu as que deux ou trois valeurs, homme, femme ou autre, et que tu as un million de lignes, et ton index il sert à rien parce qu'en fait si tu mets homme tu auras 300 000 lignes femme tu auras 300 000 lignes autre, un nom incroyable donc en fait il sert à rien ton index il va pas te dire là où la valeur, si t'as un index sur des valeurs incrémentales sur un ID par exemple celle qu'il y a de simple, il va te chercher directement l'endroit où la nuplée se trouve directement dans le système de fichier en, quelques records et donc il faut pouvoir mettre les index n'ont du sens que sur des variables qui ont une grande sélectivité donc, les variables sont très éparses et déjà un certain nombre de cas par exemple une date, généralement ça est tellement étalé le cas simple, voilà je vois.
Bruno:
Effectivement l'intérêt de l'index mais dans le cas que tu décris je vois pas le désintérêt de mettre un index partout au-delà du fait que ça prend de la place.
Cedric:
Alors après c'est le problème des stats des moteurs là tu dépasses un peu mon domaine de compétence ça fait longtemps que je ne l'avais pas fait mais, ton moteur quand tu écris ta requête il y a un plan d'exécution qui va être défini par ton moteur ton RGBDR il va te dire ok c'est une jointure je vais aller plutôt chercher la donnée à cet endroit là en existant tel index ou pas telle est le gauche denture, parce qu'il y a des dizaines, et puis après, il fait ce choix sans exécuter d'abord, sinon ça n'a pas de sens, il ne va pas tous exécuter pour dire que c'est celle-là la meilleure, donc il sert de stats. Les stats, il faut pouvoir les recalculer. C'est un peu rouillé par rapport à ça. Et donc, tes stats, il faut qu'elles soient à jour. Et donc, si elles ne sont pas à jour, tu auras un problème, déjà. Je ne sais plus ce que je voulais dire.
Bruno:
C'est sur la multiplicité des index. Qu'est-ce qui se passe quand tu as trop d'index ?
Cedric:
Et puis après, tu as les questions d'insert, effectivement, comme tu en parlais tout à l'heure. Les inserts, elles updates ou même les dilettes. Ça a un coût. si à chaque fois tu insères un élément dans ta table il faut que tu modifies tous tes index ça peut être.
Bruno:
Long et couteau, alors effectivement on me confirme dans le live qu'il y a un léger problème de micro, alors attends ce qu'on va faire c'est que je vais noter le timestamp juste pour pouvoir après pour le coup faire un peu de montage tac, je te alors en même temps je peux pas te dire ce que tu veux aux invités parce que je vais bidouiller ton micro. Mais j'espère que ça va se corriger.
Cedric:
Qu'est-ce qu'il faut que je fasse ? Je ne vois rien, mais je... Ça faisait longtemps que je n'avais pas eu un problème en live.
Bruno:
Le truc, on a reset le branchement.
Cedric:
J'espère que ça va. Tu veux que je parle un petit peu ? Est-ce que ça va mieux ?
Bruno:
Le truc, c'est que c'est aléatoire, en fait.
Cedric:
Oui, peut-être que je touche un peu le... Il ne faut pas que je touche le pied du micro.
Bruno:
Je ne sais pas du tout d'où ça venait. Mais comme on confirme dans le chat que c'était problématique... Enfin, voilà. Mais en tout cas, je me demande si ce n'est pas un problème plus global parce que j'ai l'impression que le mien aussi, parfois, coupe un peu. Mais en tout cas, merci beaucoup Solty d'avoir d'avoir noté le truc, et du coup très gentiment Solty nous aide à revenir dans la discussion en mettant la plupart des SGBDR n'utilisent que des index permettant de ne lire que 25% ou moins d'une table, rapport à trop d'index le gros souci c'est qu'un index ça se maintient lors des écritures insert update delete donc et ça ça coûte cher et donc ça c'est ce qu'on disait effectivement sur l'impact d'avoir trop, d'index, c'est qu'effectivement tes inserts et tes updates prennent beaucoup plus de temps que ce que ça devrait. Le premier point de ce qui a été dit, les GBDR n'utilisent que les index permettant de ne lire que 25% au moins d'une table. Je ne sais pas si... Moi, je ne comprends pas ce qui est dit.
Cedric:
Ça dépend si c'est en termes de colonne ou non. Ton index, si tu mets par exemple un index sur la date, c'est 100% des dates qui sont dans, sinon ça n'a pas de sens. Donc après, tu ne vas pas mettre un index sur toutes les colonnes, ce que je disais. Donc c'est peut-être dans ce sens-là, les 25%. Et généralement, tu vas regarder... Je ne sais pas toutes les colonnes. C'est là où tu vas avoir des clés de jointure, donc on va retrouver sur un ID, tous les IDs en général, ou les dates.
Bruno:
Ok. Ce qui est surtout intéressant aussi dans ce que tu dis, c'est qu'au final, pour améliorer la performance de tes requêtes ou la qualité de tes requêtes, il ne s'agit pas d'être bon uniquement en SQL. Parce que là, tu vois, on parle effectivement d'index. On commence à toucher à des sujets de structure de table, structure de l'information. Savoir faire une jolie requête SQL, c'est pas tout. Il faut savoir aussi structurer l'information de manière peu pertinente en arrière pour que ta requête soit efficace.
Cedric:
Oui, alors c'est effectivement deux métiers différents. La partie d'EBA, faire en sorte que ton système soit bien indexé. Et le fait d'écrire des requêtes efficaces. Sur le casque. Et donc, ta question, c'est qu'en fait il ne faut pas être juste bon au SQL il faut maîtriser de manière un peu plus globale le.
Bruno:
Sujet d'organisation de l'information au final.
Cedric:
Oui je ne vois pas trop pour moi c'est deux métiers différents, on peut le voir sous l'angle du data analyst qui doit connaître ce qu'il y a dans ses tables et le sens et la sémantique de chaque donnée et écrire une requête pour extraire la donnée, répondre à une question et, Et a priori, faire en sorte que sa requête ne prenne pas trop de temps. Et après, effectivement, tu as le DBA qui va aller optimiser tout ça, s'il y a des problèmes sur les GBDR. Après, nous, chez les Führers, on n'est plus dans les GBDR, c'est pour ça que je suis un peu rouillé. On utilise BigQuery intensivement. Et donc là, on ne parle pas d'index, on parle de clé de partitionnement, en général, la date. Et les requêtes, ce sont de manière très efficace. on a plutôt regardé la taille de données qu'ils manipulaient pour être raisonnable, plutôt que les temps d'élection, parce que ça se fait de manière très rapide.
Bruno:
Il y a un point, je ne me souviens jamais plus de l'exact exemple de l'histoire, mais dans une expérience précédente, j'avais pu échanger avec des gens qui étaient un peu plus, bien plus experts que moi en base de données, et notamment on avait réussi à optimiser une requête parce que j'avais changé le contenu d'un champ parce que du coup on passait d'une comparaison, de caractères je crois que l'exemple le plus rudimentaire c'est que tu passes d'un oui non à un 0 1 et que du coup quand tu vas chercher un O versus chercher un 0 ou quand tu vas chercher un 1 versus un N, en fait le temps d'exécution est plus rapide dans le cadre du, chiffre parce que c'est plus rapide de faire une comparaison de chiffres qu'une comparaison de lettres.
Cedric:
Après ça dépend aussi de la structure de ta lettre si t'es juste si t'es sur un blob ou n'importe quoi ou ça peut être, un VARCAR généralement sur du MySQL la recherche sur des in sont plus efficaces que de la recherche par caractère voire même un mot si t'es oui c'est compliqué faut regarder le premier deuxième, troisième caractère s'assurer qu'il n'y a rien derrière si t'as une qualité stricte, ou un like si tu mets un pourcent et tu veux juste vérifier qu'il y a un oui t'es obligé de partout parcourir c'est des choses qui sont compliquées la recherche de texte et qui prennent du temps, Donc il faut, effectivement, en fonction des requêtes que tu peux poser, est-ce que tu peux faire du pré-traitement, donc restructurer et dire, par exemple, tu pourrais imaginer dans ton cas, si tu as du oui ou du non, tu cherches juste tout le temps. Est-ce qu'il y a du oui ou du non dans mes textes ? Et donc, pré-calculer une seule fois pour toutes et créer une colonne, dans ce texte il y a oui, dans ce texte il y a non. Ils ont juste recherché. Donc là, tu pourrais mettre un boulot, dire 0, 1 là-dessus, pour rechercher, il serait plus efficace.
Bruno:
Donc tu vois, on revient en fait au fait que pour savoir faire des requêtes, SQL efficace, il faut du coup maîtriser un peu ce qui se passe derrière la mécanique qui est avec.
Cedric:
Oui, mais c'est pareil aussi avec n'importe quel langage.
Bruno:
Alors, je suis d'accord.
Cedric:
Même niveau peut-être.
Bruno:
Mais voilà, j'ai l'impression que c'est plus pertinent, enfin, c'est plus vite une nécessité que quand tu fais du SQL, de connaître la mécanique de ton SGBDR, que quand tu fais du dev en PHP ou du dev Java ou javascript où t'as je pense moins vite besoin, de maîtriser comment fonctionne la JVM ou comment fonctionne le navigateur enfin tu vois j'ai l'impression que c'est moins vite un critère différenciant.
Cedric:
Oui ouais peut-être effectivement avec la JVM il y a tout un tas de choses dont t'as plus besoin de publier c'est pas forcément le cas avec le C c'est l'évolution des langages qui font que c'est plus pratique, effectivement alors on peut revenir sur SQL on parlait sur le compilé on disait que Git avait 20 ans tu sais quel âge l'SQL.
Bruno:
Alors ça c'est une bonne question je dirais que le SQL ça vient des années 60, donc pour moi on est à 60 ans à peu près.
Cedric:
C'est 74 le SQL.
Bruno:
74 donc c'est quand même plus jeune que.
Cedric:
Ça fait quoi ça fait 50 ans 51 ans c'est pas mal une dame vachement sexy 51 ans et le modèle relationnel c'est les années 70 par Edward Code, et donc oui effectivement il y a eu des évolutions depuis c'est très basique, je ne sais plus pourquoi on parlait de ça, sur l'évolution oui il y a besoin de comprendre le modèle relationnel comment ça fonctionne derrière mais dans les cours qui sont enseignés on ne t'apprend pas juste l'SQL pour le SQL, on te donne aussi l'index, on n'a pas parlé mais aussi l'index avec les étrangères, je crois qu'il faut que tu te rapproches de ton micro pardon merci je disais quoi parce qu'on parle des index c'est les index primaires les index secondaires il y a les clés étrangères il y a quoi, il y a la mise en forme normale les différentes formes normales à prendre en compte dans ton schéma de base de données voilà.
Bruno:
Ce qui est intéressant aussi dans cette, perception qu'il faut avoir de ton GBDR, c'est qu'il y a aussi des... Il faut aussi maîtriser le moteur de la base de données qui est utilisé. Moi, quand je commençais, je choisissais quasiment random quand je faisais du MySQL entre MyZam et Inodb. Et puis un jour, quand tu commences à être sur des projets un peu plus costauds, il y a des gens qui t'apprennent qu'ils se disent qu'il y a un vrai impact. Je sais pas à quel point moi ça fait un petit moment que je suis plus trop sur des sujets de prod mais je sais pas à quel point il y a encore que MyZem et Inodb qui se battent ou s'il y a d'autres moteurs où c'est encore un combat je.
Cedric:
Me rappelle de MyZem et Inodb effectivement c'est pas la même chose de mémoire Inodb c'est transactionnel, il fallait plutôt utiliser Inodb ce qui n'est pas le cas de MyZem et bon, oui je me rappelle après c'est MySQL mais, il n'y a pas que ça.
Bruno:
On me précise dans le chat que MyZam est déplicated donc il faut maintenant passer plutôt sur du InnoDB j'imagine, est-ce que pour toi il y a un intérêt à avoir une, guerre de bases données là on parle beaucoup de SQL qui est un langage que tu peux utiliser sur du MySQL, sur du Oracle, sur du Postgre, sur beaucoup de schémas possibles. Est-ce que pour toi, au final, c'est kiff-kiff, la base de l'éclairage, ou il y a quand même un contexte où pour toi, il n'y a pas de one-size-fits-all ? Je ne sais pas quel est ton point de vue là-dessus.
Cedric:
Il y a forcément des gardes-clochers. Il n'y a pas exactement les mêmes dialectes, SQL. Mais pour moi, je pense que ça doit être sur une logique... One-Side-Fits-All, ta requête SQL devrait être exécutée partout, et c'est pour ça aussi qu'il faut rester dans une logique très simple, pas chercher à faire des choses très complexes, de mon point de vue, pour que ça reste lisible et que tu puisses l'exécuter sur n'importe quel moteur, que ça soit portable, dans cette logique-là.
Bruno:
Oui, mais alors, tu vois, tu parles de lisibilité, que ce soit portable, comme je le disais, je crois que c'était sur le compilé où j'évoquais ça, c'est que pour la majorité des devs, une requête SQL, on parle de 3, 4, parfois... Je sais que j'ai déjà fait des requêtes SQL qui visaient environ 10 lignes, parce que je faisais des saut de lignes pour que ce soit propre, que ce soit lisible. J'avais l'impression de faire un truc un peu fancy. L'autre jour, on discutait, parce que Cédric et moi travaillaient ensemble chez les Furets, et tu m'as sorti une requête SQL, on parlait d'un fichier je sais plus, qui était de l'ordre de 60 lignes, pour moi ça me paraît inconcevable de me dire que tu as une requête SQL qui fait 60 lignes j'ai envie de te dire on va faire du code, pour faire ça en quelques requêtes SQL et faire quelque chose de plus optimisé 60 c'est.
Cedric:
Trop pour toi.
Bruno:
? oui pour moi il y a un problème quelque part.
Cedric:
Oui peut-être un peu plus simple.
Bruno:
C'est aussi que vous êtes vous sur des sujets qui sont quand même beaucoup plus complexes sur des appréhensions. Donc on parle d'un nombre de tables et de champs qui sont beaucoup plus importants et un traitement de l'information. C'est-à-dire que l'information que tu sors de ta requête SQL, toi, elle est déjà énormément traitée. En fait, elle est déjà énormément processée.
Cedric:
Ça dépend à quel niveau tu te places. Tu peux aussi être en amont et pas donner plus brut. Mais effectivement, quand tu vas te placer dans le cas du Data Warehouse, Effectivement, quand tu vas te passer dans le cadre d'un Dataverse, je me rapproche du micro, je suis désolé. Quand tu te rapproches du Dataverse, quand tu es au niveau du Dataverse, les données sont pré-processées, leur sens est clair, il n'y a pas de piège, il doit y avoir une sémantique, c'est la logique, et que ce soit utilisable par à peu près n'importe qui. Sans trop se poser de questions. Mais tu vas remonter en amont, parce qu'avant, la donnée source, elle n'est généralement pas au même niveau, et donc tu vas à ses différents niveaux. Si tu mets d'un point de vue du data analysis, la data analysis a juste modifié. Roqueter le data warehouse où les données sont claires. Et donc, je m'appelle ta question.
Bruno:
Non, mais c'est qu'en fait, toi, quand tu fais une requête SQL qui, effectivement, va faire plusieurs dizaines de lignes, c'est qu'en fait, toi, ta requête, elle fait déjà une grosse partie de traitement de l'information, que ce soit de la mise en forme, du genre de choses. Là où, effectivement, pour beaucoup de devs, c'est que je récupère des éléments et après dans mon code je vais les traiter Oui.
Cedric:
Oui mais après a priori ce que tu peux faire en SQL tu peux le faire dans n'importe quel langage tu peux très bien te serrer de SQL pour générer un CSV quelque part et après tu te débrouilles et tu vas manipuler, tes opérations de jointure mais là il faut que tu fasses toi-même tes jointures il faut que tu les recodes, les égalités tu pourrais imaginer si t'es pas à l'aise avec UASQL, autant le faire. Mais là, tu vas avoir ton code Java qui ne va pas faire 60 lignes, il va faire beaucoup plus. Surtout en Java donc après on pourrait comparer on pourrait faire l'exercice ça serait intéressant et peut-être que tu te diras ok effectivement mes 60 lignes, en un coup d'oeil quand t'es habitué c'est toujours pareil, ça va être plus lisible et plus clair et m'explique ce que ça fait plus simplement, que mon code Java j'ai du mal avec Java pourtant j'en ai fait.
Bruno:
Et on évoquait tout à l'heure en début d'épisode les ORM où tu me disais quel dommage d'avoir des devs qui ne font plus de requêtes SQL. Est-ce que ce n'est pas aussi, une conséquence ou un symptôme du fait que SQL est un langage qui est beaucoup plus puissant ou profond que ce que la majorité des gens l'utilisent réellement ? Ce qui veut dire que ça ouvre aussi la porte. Quand tu le fais mal, on peut parler bien évidemment d'injection SQL, qui est aussi un des premiers gains pour les ORM, mais de manière un peu plus globale. Comme c'est un outil qui est extrêmement profond, que les gens le fait, le survolent. L'ORM, c'est un moyen de s'assurer que les gens ne font pas n'importe quoi dans ce contexte-là. Est-ce que pour toi, c'est une disparition d'une connaissance nécessaire, ou c'est plutôt une bonne chose, parce que tu voyais qu'en fait, les devs Java, PHP ou autres, faisaient en fait des requêtes SQL qui étaient, de toute façon, une aberration ?
Cedric:
Non, c'est pas forcément le cas. Alors, pour tes derniers points, non, j'ai le choix des devs qui font des bonnes requêtes SQL. En fait, ils n'ont pas non plus en général besoin de faire de très très grosses transformations et donc tu peux juste récupérer les éléments qui t'intéressent parce que généralement, ça a été travaillé, transformé et mis à disposition dans les data warehouse. Ouais, un peu plus en amont. Après, c'est toujours pareil, ça dépend de ton usage. L'ORM, je n'en ai jamais eu usage, donc, de mon point de vue, personnellement, je n'ai jamais modifié avec un ORM. Après, tout le monde fait, les gens font ce qu'ils sentent le mieux, quoi. Un peu dommage, parce qu'après, quand on a besoin de comprendre la requête, la débuguer, et que la rare fois où j'ai eu besoin de la regarder, je ne comprenais pas grand-chose, la requête qui était sortie, donc ça peut-être évolue depuis mais c'est toujours un peu dommage de ne pas trop comprendre autant la réécrire de visuel et pour les problématiques d'injection oui peut-être, pareil on peut se prévenir de manière différente, voilà.
Bruno:
Pour avoir un petit débat parce que du coup moi je suis plus côté dev que côté data est-ce que tu penses que tu vois moi j'ai une, j'ai eu une période où je virais toutes les clés étrangères de mes bases de données dans ma logique qui était que ce genre de contrainte elle doit être portée par le code là où est la logique métier, et que en fait s'assurer que tes enregistrements sont bien que ta donnée est bien insérée au bon endroit de la bonne façon c'était à gérer côté code et non pas côté data, alors je te vois effectivement faire les gros yeux j'imagine que t'es pas trop aligné avec ce genre de...
Cedric:
Pas du tout j'ai.
Bruno:
Bien précisé que j'ai eu une période ça veut dire que j'en suis sorti.
Cedric:
C'est en faisant des erreurs qu'on apprend non je suis pas aligné là-dessus, les clés étrangères servent de manière très utile et sont très efficaces pour l'optimisateur du plan de requête de manière à ce que ton AGBDR va trouver le meilleur algo possible, pour que ta requête soit efficace. Si tu retires tes clés étrangères, tu vas peut-être avoir des problèmes d'exécution de tant de requêtes.
Bruno:
Oui, parce que du coup, ça c'est aussi un facteur, c'est-à-dire que c'est ce que tu évoques depuis plusieurs fois, c'est que quand tu écris ta requête, tu as un moteur qui va, optimiser de lui-même l'exécution de la requête en fonction de l'existence du schéma.
Cedric:
Oui, complètement. Suivant les cas, suivant les algos, il va essayer de chercher donc si t'as les bons index je pensais pas qu'on parlait autant d'index mais si t'as les bons index normalement ça prend du au en haut de Llogen donc de manière très efficace, alors je me répète mais qu'est-ce que je peux dire de plus, c'est tout le métier en fait derrière la recherche scientifique depuis des années je disais tout à l'heure que le modèle relationnel avait 1970 donc 55 ans, et oui c'est non.
Bruno:
C'est 74 ouais.
Cedric:
Ouais bon le SQL donc derrière il y a eu beaucoup de travaux de recherche sur quels sont les bons algos comment faire pour optimiser tout ça il y a eu de la recherche scientifique là-dessus.
Bruno:
Mais tu vois c'est quand même un truc que je trouve assez étonnant ce que tu évoques c'est que le côté SQL et le côté base de données c'est deux métiers différents comme tu disais tout à l'heure mais je trouve que l'impact de l'un sur l'autre est quand même hyper important. J'en suis presque étonné que ce soit des métiers différents, tellement l'un impacte l'autre.
Cedric:
Tu peux faire aussi les deux, mais tu peux faire les deux, bien sûr. Mais tu peux aussi n'être que data analyst et ne travailler que l'OSQL sans forcément bien comprendre comment ça fonctionne derrière. Je ne sais pas que tous les data analystes sont comme ça, mais tu peux imaginer qu'un pilote de voiture, ce n'est pas forcément comment fonctionne moteur de voiture, mais il y en a certains qui savent comment ça fonctionne et qui rendent beaucoup plus vite et qui maîtriseront mieux leur voiture.
Bruno:
Oui, ça montre encore une fois la philosophie de ce podcast, c'est qu'il faut s'intéresser à autre chose que sa stack quotidienne et c'est ce qui nous rend tous et toutes, bien évidemment, meilleurs sur le sujet. C'est quoi pour toi le truc dans l'ESQL qui est sous-exploité ou sous-coté ou qui n'est pas suffisamment connu ?
Cedric:
Clairement, ce que je disais tout à l'heure, les Windows Functions, le fenêtrage. J'ai découvert, alors que j'ai enseigné longtemps, je ne le savais pas. Alors, ça arrivait un peu sur le tard aussi, mais je trouve que c'est vraiment sous-coté. Il faut regarder les parties, les Windows Functions en SQL.
Bruno:
Ça peut être quoi le gain, pour un développeur ou une développeuse lambda d'aller s'intéresser à ça ? Ce serait quoi le truc que tu pourrais nous expliquer pour nous mettre l'eau à la bouche et nous donner envie d'aller creuser ?
Cedric:
Je pense que c'est déjà une question de lisibilité. Je pense qu'on est tous dev, on adore avoir du code lisible clair et on a tous expérimenté qu'on se replongeait dans son propre code un an, deux ans, trois ans après et de comprendre ce qu'on a écrit. Je pense que la lisibilité est très importante et ça rend des requêtes SQL beaucoup plus lisibles, parce que le sens se trouve en une seule ligne, vous, Est-ce que je pourrais dire d'autres là-dessus ?
Bruno:
En fait, moi, je veux bien creuser un peu ce sujet, parce qu'autant la partie function, je vois à peu près ce que ça peut être, mais le côté window, j'ai du mal à comprendre. C'est quoi la différence entre une window function et une fonction traditionnelle telle qu'on le ferait dans n'importe quel autre langage ?
Cedric:
Je ne sais pas de l'expliquer comme ça. Je ne sais pas trop quoi dire là-dessus. comment je peux te l'expliquer ? Effectivement, tu peux le voir sous forme de fonction appliquée à l'ensemble de tes données qui sont traitées en cours à ta table. Généralement, quand tu appliques un where, tu vois, select from where, le where, ça s'applique après. Je fais une disgression, c'était intéressant. Un des problèmes du select from where, ce qui rend peut-être aussi les choses un peu compliquées, c'est que ça ne s'exécute pas dans l'ordre quand on le réfléchit, c'est pas dans le même ordre, donc en fait on parle de select fromware mais le select c'est un peu ce qui s'applique en dernier c'est le résultat de ce que tu dis, le résultat que tu veux tu le mets en premier c'est logique de l'avoir en dernier, et le from qui serait à partir de mes données d'ailleurs from à partir de tu voudrais l'attendre en premier on pourrait plutôt avoir un fromware select plutôt, donc à partir de mes données j'applique un filtre et je veux ça, donc ça c'était aussi une explication de pourquoi on peut avoir du mal à m'y avoir et puis pareil après sur les groupes by, les orders des fois on ne peut pas forcément comprendre et quand on n'a pas la logique, on ne l'a pas acquise, on peut s'y perdre et donc sur les Windows Functions, il faut le voir, non pas sur un where qui va s'appliquer un peu en dernier mais directement sur cette structure de données en cours, je vais y appliquer un fonction d'agrégat et retourner une réponse.
Bruno:
T'as évoqué tout à l'heure les clés de partition pour BigQuery ça pour le coup je connais les clés d'index mais c'est quoi une clé de partition ?
Cedric:
BigQuery ce n'est pas un GBDR donc tu as des index c'est la façon simple de le voir où en fait à l'origine chaque, NUPlay est dans des fichiers disques où ton index il va te permettre d'aller te dire précisément où est ce fichier disque, on pourra le recharger rapidement, après il y a tout un tas d'optimisation, de cache là-dessus donc on n'est pas dans ce cadre-là sur BigQuery, on est plutôt dans une logique j'ai tout chargé, donc si tu fais un select where est dit égal à 1 tu attends dans un AGBDR qui va ne chercher qu'un seul enregistrement, mais BigQuery il va aller tout lire et après il applique le filtre. C'est une forme de colonne. S'il n'y a pas la partition sur l'ID, tu pourrais mettre une partition sur l'ID. En général, ce qui est plus simple dans un cas de Pro, chez nous, c'est de mettre une partition sur la date. En fait, il va y avoir des gros fichiers stockés par date. Quand tu mets à mettre sa partition, la date, un fichier par date, en gros, la manière de le représenter. Quand tu mets une date, au lieu d'aller chercher toutes tes données, tes gigas, tes terras de données, il va juste chercher le fichier. T'as 3 ans donc t'auras juste 1 pour 1000 de tes données donc.
Bruno:
Ça c'est dans le cadre précis de.
Cedric:
BigQuery c'est important de bien mettre des partitions parce que comme tu payes, à la lecture des données 1 Tera c'est pas la même chose qu'1 giga c'est 1000 fois plus cher c'est intéressant de faire attention à ça ouais.
Bruno:
Alors, justement, c'est intéressant que tu parles de BigQuery, parce qu'un des points que je voulais évoquer sur la fin, c'était effectivement le passage au NoSQL. On voit de plus en plus de technos de base de données arriver qui essaient de s'extraire du langage SQL et de proposer des outils de requêtage un peu différents, où tu fais ça avec un objet JSON, où tu vas mettre un ensemble. Tu es plus sur du SQL en tant que tel est-ce que pour toi c'est une évolution logique parce que la manière qu'on est passé de langage de plus en plus orienté objet, de plus en plus haut niveau on a besoin de s'extraire de ce côté très procédural du SQL pour revenir à quelque chose d'un peu plus.
Cedric:
De mon expérience j'ai l'impression que ça restera longtemps j'ai eu plusieurs choses quand j'étais en thèse je travaillais sur la transformation de documents XML et donc à l'époque il y avait un langage, on avait du XPass et du XSLT pour transformer tes documents c'était pas du SQL et donc il y avait déjà à ce moment là une logique on va faire du SQL, on n'y comprend rien, SQL-like qui était le XQuery, pas trop marché je me rappelle de Cassandra si on a un peu travaillé là-dessus et pendant tout un temps Cassandra était difficile à utiliser s'il n'y avait pas le SQL qui était le Cassandra Query Langage c'est très proche du SQL, et Bikuri marche très bien aussi aujourd'hui parce que je pense qu'il y a le SQL ça parle à tout le monde, les gens ont été formés sur le SQL la plupart des devs et que ça simplifie vachement, le requêtage donc je pense que le SQL a de longs jours devant lui et qu'on n'est pas prêt de l'arrêter.
Bruno:
Sous réserve qu'on reste dans un monde où ce sont des êtres humains qui ont besoin d'écrire des requêtes, pour aller chercher de l'information, là où demain.
Cedric:
Peut-être Ah peut-être que on n'aura plus besoin d'écrire sa requête et qu'on l'exprimera à l'oral et que la requête elle sera faite en fait on ne verra pas du tout comment ça marche Et.
Bruno:
Ce sera une autre façon de faire Peut-être Très bien, écoute merci beaucoup Cédric pour cette conversation autour du SQL c'était passionnant, pour terminer j'aurais deux dernières questions pour toi, qui sont les questions rituelles du podcast. La première, c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes ?
Cedric:
Je ne sais pas trop, effectivement. Je pense que il y a un livre qui m'a un peu posé la question. Il y a un livre de SF que j'ai toujours aimé, que j'ai même lu plusieurs fois depuis que je suis tout petit. C'est Le fleuve de l'éternité de Philippe José Farmer. Je pense qu'il est sous-coté. Je rêverais d'en voir une série Netflix d'ailleurs basée sur ce livre. Donc si vous ne connaissez pas allez le lire il y a 5 ou 6 tomes.
Bruno:
Très bien on mettra le lien bien évidemment en description et la dernière question qui est de loin la plus importante de ce podcast tu es plutôt espace ou tabulation. Espace très bien merci beaucoup Cédric c'est moi et merci à tous d'avoir assisté à cet épisode j'espère que vous avez donné envie d'aller faire un petit deep dive sur le SQL parce que qui est quand même un langage, assez formidable et qui permet de faire beaucoup de choses aller creuser donc ces fameuses Windows functions qui vont vous permettre de faire peut-être plus de choses dans votre requête SQL plutôt que de le faire en code derrière. Donc c'est toujours intéressant et ça montre bien qu'il faut savoir s'intéresser à autre chose pour être toujours plus efficace, meilleur et apporter des solutions qui ont plus de valeur. Je vous remercie aussi comme toujours de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine et d'ici là, codez bien !
