Depuis sa création dans les années 1970 par IBM, le langage de requête structuré, mieux connu sous l’acronyme SQL, est devenu la pierre angulaire des bases de données relationnelles. Cinquante ans plus tard, SQL reste un outil incontournable dans le monde de la technologie de l’information, malgré l’émergence de nouvelles technologies et approches de gestion des données. Les premières bases de données informatiques sont apparues à la fin des années 1960. C'était un domaine de recherche important à l'époque. De nombreux informaticiens se sont attachés à améliorer le fonctionnement des bases de données. L'un d'eux était Edgar Frank (Ted) Codd, un informaticien anglais employé chez IBM. Dans les années 1940, il a pris part au projet de calculateur électronique à séquence sélective, le premier ordinateur électromécanique au monde.
Mais ce qui rend Codd vraiment célèbre, c'est un article publié en 1970 intitulé A Relational Model of Data for Large Shared Data Banks (littéralement « un modèle relationnel de données pour les grandes banques de données partagées »), qui a marqué le début de l'ère des bases de données relationnelles en informatique. Codd est donc souvent considéré comme l'ancêtre de SQL. En 1981, il a reçu le prix Turing, la plus haute distinction en informatique, considéré par de nombreuses personnes comme l'équivalent du prix Nobel pour l'informatique.
À l'époque où Codd a écrit son article, les bases de données hiérarchiques et en réseau étaient dominantes. Elles étaient également assez peu flexibles. Pour extraire des données de la base, il fallait essentiellement écrire un programme informatique : les données n'étaient pas accessibles aux non-programmeurs. Toute modification du modèle nécessitait des changements dans les modèles d'accès aux données - en d'autres termes, les programmes d'accès aux données devaient essentiellement être réécrits.
Dans son article, Codd proposait une idée totalement nouvelle : modéliser les données avec la notion mathématique de relations (aujourd'hui, nous les appelons des tables). Le modèle de données relationnel de Codd offrait une plus grande flexibilité que les modèles de données hiérarchiques et en réseau. De nouvelles relations pouvaient être ajoutées sans modifier les relations existantes. Grâce à ses idées, le travail avec les bases de données est devenu beaucoup plus facile.
En mai 1974, Donald Chamberlin et Raymond Boyce ont publié un article sur SEQUEL (un acronyme de Structured English QUEry Language), un langage de requêtes structurées qui pouvait être utilisé pour gérer et trier des données. Plus tard, SEQUEL a été renommé SQL en raison d'un problème de marque déposée.
Malheureusement, Ray Boyce est décédé peu de temps après avoir posé les bases de SQL ; il n'a jamais pu voir l'impact qu'il aurait.
Il est intéressant de noter que Donald Chamberlin ne considérait pas SQL comme un bon langage pour la façon dont il était utilisé à l'époque. En 1995, il a déclaré :
Envoyé par Donald Chamberlin
Lorsque Ray et moi avons conçu Sequel en 1974, nous pensions que l'utilisation prédominante du langage serait pour des requêtes ad-hoc par des planificateurs et d'autres professionnels dont le domaine d'expertise n'était pas principalement la gestion de bases de données. Nous voulions que le langage soit suffisamment simple pour que les gens ordinaires puissent l'utiliser avec un minimum de formation. Au fil des ans, j'ai été surpris de constater que SQL est plus fréquemment utilisé par des spécialistes des bases de données formés pour mettre en œuvre des transactions répétitives telles que les dépôts bancaires, les achats par carte de crédit et les ventes aux enchères en ligne. Je suis heureux de voir le langage utilisé dans des environnements variés, même s'il ne s'est pas avéré aussi accessible aux utilisateurs non formés que Ray et moi l'espérions au départ.
L’évolution de SQL
SQL a évolué avec le temps, s’adaptant aux besoins changeants des entreprises et aux progrès technologiques. Avec l’avènement du cloud computing et des mégadonnées, SQL a dû s’adapter pour gérer des volumes de données toujours plus importants et offrir des performances optimales.
Selon Stack Overflow, SQL est le troisième langage le plus utilisé par les programmeurs et les développeurs de logiciels. En 2023, l'IEEE a noté que SQL était le langage le plus populaire pour les développeurs lorsqu'il s'agissait de trouver un emploi, en raison de la façon dont il pouvait être combiné avec d'autres langages de programmation.
Au cours d'une interview, Peter Zaitsev, fondateur de Percona, a tenté d'expliquer comment SQL a évolué dans le temps :
« Ce que je trouve intéressant, c'est que le langage SQL est en quelque sorte une lentille : il vous montre comment les gens préfèrent travailler à un moment donné. Je veux dire par là que le langage SQL a toujours su trouver des solutions aux problèmes modernes, depuis sa création jusqu'à aujourd'hui. Par exemple, il y a une vingtaine d'années, le XML (langage de balisage extensible) était très important, n'est-ce pas ? En réponse, des éléments tels que XPAth et Xquery ont été introduits dans la norme SQL afin que les gens puissent travailler avec des données XML. SQL a ensuite ajouté les données GIS (système d'information géographique), car les données de localisation étaient devenues plus importantes. Au cours des années suivantes, tout est passé à JSON, qui a pratiquement remplacé XML pour travailler avec des documents structurés. SQL a donc ajouté de nombreuses fonctionnalités permettant de travailler avec des objets JSON stockés dans une base de données.
« Lorsque vous parlez de SQL en tant que langage, nous devrions parler de SQL comme d'une famille de langages. Car si vous pensez à Python, par exemple, c'est un seul langage, n'est-ce pas ? Mais chaque base de données implémente SQL différemment. Bien que SQL soit une norme, je ne suis pas sûr que tout le monde l'applique de la même manière. Toutes les bases de données ont tendance à ajouter des extensions supplémentaires en fonction de l'objectif de la base de données. Il peut donc y avoir des différences dans la façon dont Postgres travaille autour de SQL par rapport à MySQL et SQL, et elles seront différentes de celles d'Oracle. Par exemple, vous pouvez constater que les choses fonctionnent différemment en termes d'isolation des transactions dans MySQL et Postgres, même si vous exécutez les mêmes requêtes sur les deux. Cela peut conduire à des résultats différents. Je pense qu'il s'agit là d'un exemple de la capacité de SQL à réussir au fil du temps, mais c'est aussi une nuance que nous devons comprendre.
« Même si nous disposons du même langage ou d'une version très similaire, tout se jouera au niveau de l'implémentation. C'est là que les choses peuvent être très différentes. Nous voyons toutes les équipes de bases de données innover autour de SQL, puis les meilleures idées sont copiées par d'autres fournisseurs. Finalement, ces décisions d'implémentation réussies seront intégrées dans la norme, de sorte que tout le monde puisse en bénéficier ».
SQL et NoSQL : une coexistence Nécessaire
L’apparition de NoSQL dans les années 2000 a marqué un tournant, offrant une alternative aux bases de données relationnelles pour des cas d’utilisation spécifiques nécessitant une grande scalabilité et une structure de données flexible. Cependant, plutôt que de remplacer SQL, NoSQL s’est positionné comme un complément, chaque type de base de données ayant ses propres avantages et cas d’usage idéaux.
La plupart des grandes entreprises utilisent une architecture de persistance polyglotte, c'est-à-dire qu'elles utilisent de nombreuses techniques de stockage de données différentes pour répondre aux différents besoins de l'organisation.
Google, par exemple, dispose d'un mélange de bases de données relationnelles et NoSQL, chacune adaptée à une tâche différente. Google BigTable est une base de données NoSQL adaptée aux charges importantes. Elle est complétée par Spanner, leur propre base de données relationnelle. BigQuery est une base de données SQL relationnelle utilisée pour l'entreposage de données, qui permet d'extraire divers types de données analytiques.
YouTube, la filiale de Google, utilise MySQL (un système de gestion de base de données relationnelles très populaires) comme principale installation de stockage de données. Mais pour lui donner une certaine évolutivité, elle le gère à l'aide de l'utilitaire de regroupement de bases de données Vitess.
Ainsi, bien que Google utilise NoSQL à sa juste place, les bases de données relationnelles et SQL sont, et continueront d'être, une partie essentielle de leur technologie.
Uber
Les besoins d'Uber en matière de données sont variés. Un grand nombre de conducteurs et de passagers ont besoin d'un accès instantané aux données afin de coordonner les besoins de transport. Les analystes de données ont besoin d'accéder à des pétaoctets de données pour planifier et synchroniser les opérations. Les développeurs ont besoin d'accéder aux données pour améliorer et étendre les services d'Uber.
Uber utilise Hadoop pour permettre à ses vastes entrepôts de données d'être mis à l'échelle horizontalement. La gestion de la base de données sous-jacente est assurée par les serveurs MySQL. Les requêtes peuvent être effectuées de différentes manières, notamment en SQL pur et en Presto, qui utilise également la syntaxe SQL.
Facebook s'appuie sur la technologie MySQL via son propre moteur de base de données MySQL, MyRocksDB.
Nous pouvons donc constater que SQL fait partie intégrante des opérations des grandes entreprises et qu'il en sera probablement de même dans un avenir proche.
Les défis actuels et futurs
Aujourd’hui, SQL doit relever plusieurs défis, notamment l’intégration avec le traitement en flux (stream processing) et l’analyse en temps réel des données. Les entreprises doivent également prendre en compte la sécurité des données et la conformité réglementaire, en particulier dans des environnements cloud.
SQL et l’avenir de la science des données
En 2024 et au-delà, SQL devrait continuer à jouer un rôle clé dans la science des données, notamment en facilitant la préparation et la transformation des données pour les modèles d’apprentissage automatique. Sa familiarité et sa flexibilité en font un choix privilégié pour les tâches de manipulation de données.
Voici ce que pense Peter Zaitsev de l'avenir de SQL :
« Il est intéressant de voir comment la technologie progresse. De plus en plus de domaines technologiques sont devenus suffisamment performants pour fonctionner et être utilisés pendant très longtemps. À mon avis, on peut imaginer le nombre de systèmes créés aujourd'hui qui fonctionneront encore dans 50 ans. Je pense que c'est toujours une bonne question à poser : "Qu'est-ce qu'être en production signifie vraiment ?" parce que nous devons penser à ce que nous écrivons en termes de code et de fonctions, par rapport à ce que nous utilisons pour écrire ces nouvelles applications. Nous ne devrions pas penser à utiliser la version 3.2 de quelque chose par rapport à la version 3.4, mais plutôt à la raison d'être de quelque chose, et à la raison pour laquelle cette chose sera nécessaire dans un délai aussi long. C'est une question à laquelle il est beaucoup plus difficile de répondre, car certaines de ces applications ne dureront pas aussi longtemps et d'autres y parviendront sans ce type de planification.
« Aujourd'hui, nous assistons à une grande transformation, où l'IA modifie nos processus de développement de logiciels et le champ d'application potentiel de l'ingénierie logicielle. Nous pouvons utiliser l'IA pour générer du code, mais ce n'est pas tout à fait exact, nous en sommes donc encore aux premières étapes et nous devons décider du rôle que nous voulons que les humains jouent dans l'élaboration de ce code.
« Pour SQL, l'IA peut créer ce code et écrire ce qu'elle pense être la requête. Mais cela ne signifie pas que la requête sera correcte ou qu'elle fonctionnera. Elle aura l'air correcte et pourra s'exécuter, mais il se peut qu'elle ne soit pas efficace ou qu'elle ne produise pas les résultats que vous souhaitez obtenir. Ces outils doivent donc être considérés comme de simples outils. Vous devrez toujours connaître le langage SQL pour comprendre ce que l'IA vous propose comme option, afin de pouvoir la juger de la bonne manière. L'IA peut cacher une partie de ce qui se passe autour de SQL, mais elle restera la base de beaucoup de ces nouvelles applications que nous utilisons ».
Conclusion : SQL est-il toujours pertinent ?
Malgré son âge, SQL reste pertinent et essentiel pour de nombreuses carrières dans le domaine de la technologie. Apprendre SQL est considéré comme un investissement sûr pour l’avenir, car il continue d’être largement utilisé et sera probablement nécessaire pour les années à venir. Les innovations dans la technologie SQL offriront de nouvelles opportunités et défis, permettant aux entreprises de gérer des ensembles de données massifs, d’améliorer les performances des requêtes et d’améliorer la sécurité des données.
Et Peter Zaitsev de déclarer :
« Je pense que SQL a eu du succès parce qu'il nous a donné un langage de données - un ensemble d'outils qui pouvaient être utilisés pour travailler avec des données et les manipuler - et une fois que les gens ont commencé à l'utiliser, ils étaient plus susceptibles de continuer à l'utiliser. Les données sont très, très collantes, elles ont leur propre gravité et une fois que vous êtes dans leur orbite, vous allez continuer à travailler de la même manière. Il est difficile de s'éloigner de quelque chose qui fonctionne. Si vos données se trouvent dans une base de données qui utilise SQL, vous êtes en quelque sorte coincé dans l'utilisation de SQL ».
Sources : SEQUEL, IEEE
Et vous ?
Comment voyez-vous l’évolution de SQL dans les prochaines décennies ? Quels sont les défis que vous pensez que SQL devra surmonter pour rester pertinent ? Comment la coexistence de SQL et NoSQL influence-t-elle votre approche de la gestion des données ? 
