Les ingénieurs de données ou les scientifiques de données qui travaillent avec SQL devraient le traiter comme du code source, affirme un professionnel des données sous le pseudonyme de “DataExpert”.
Dans un blog publié le Génie du développeurune publication de Medium, l’auteur a fait valoir que la gestion de SQL en tant que code devrait être intégrée à la stratégie de données de toutes les organisations, y compris les plus petites.
Comme on pouvait s’y attendre, le message a généré de nombreuses discussions de la part des analystes de données et d’affaires. Mais d’abord, pourquoi les professionnels des données et les scientifiques des données citoyens devraient-ils se soucier de SQL ?
SQL est là pour rester
SQL ou Structured Query Language a été conçu pour accéder et gérer les données dans les systèmes de gestion de bases de données relationnelles (SGBD). Développé pour la première fois en 1970, SQL est aujourd’hui généralement utilisé avec des langages de programmation tels que Python pour récupérer des données à partir de systèmes de bases de données d’entreprise pour une analyse plus approfondie.
En effet, SQL est tellement ancré dans les référentiels de données qu’il est pratiquement impossible de l’éviter, même dans les systèmes de bases de données basés sur le cloud ou les plates-formes de données de nouvelle génération.
Par exemple, lorsque Bob Muglia, ancien PDG de Snowflake, a récemment parlé de l’état des plates-formes de données et de la manière dont les systèmes analytiques fusionneront avec les plates-formes de données, il a concédé que SQL continuera à jouer un rôle crucial pour le moment.
“Je pense que vous verrez des systèmes analytiques fusionner avec les plates-formes de données… Vous verrez une pile très complète qui comprendra à la fois des systèmes d’analyse et d’analyse avancée et d’apprentissage automatique, ainsi que des systèmes de gestion de données basés sur SQL”, a déclaré Muglia. en disant.
En un mot, la connaissance de SQL est vitale pour ceux qui travaillent dans les données et est utile pour les analystes ou les gestionnaires ayant besoin d’interroger des bases de données.
S’il ressemble et fonctionne comme un code de programmation
Comme le code orienté objet, SQL prend beaucoup de temps à écrire, déboguer et maintenir, écrit DataExpert, et doit donc être traité comme du code de programmation.
Cela nécessite un système transparent pour déployer un nouveau code SQL ou apporter des modifications à l’environnement de développement. Ce n’est qu’alors que les pannes peuvent être identifiées et corrigées instantanément – ou dans le cas où des bogues sont introduits par inadvertance, pour ramener la production au dernier état de fonctionnement.
Pour y parvenir, les organisations doivent abandonner leur traitement de laisser-faire de SQL pour une approche plus disciplinée. Les scripts existants doivent être centralisés dans un emplacement global et les modifications apportées aux instructions SQL doivent être méticuleusement suivies. Enfin, les modifications apportées à SQL doivent être testées et approuvées par un autre ingénieur avant que les modifications de code ne soient validées dans le référentiel.
Comment les organisations devraient-elles commencer ? “Choisissez un référentiel de code et respectez-le. Le référentiel de code devrait idéalement être partagé avec l’ingénierie, mais à tout le moins, centraliser tout le code SQL dans un référentiel. Cela devrait inclure toutes les fonctions de données telles que l’ingénierie des données, l’analyse, [and] intelligence économique », écrit-il.
L’auteur a également recommandé aux organisations de mettre en œuvre un environnement de développement approprié, d’utiliser le contrôle de version pour détecter les modifications erronées apportées à la base de code et de rendre la base de code plus accessible aux employés concernés de l’organisation.
Prendre une longueur d’avance
En réponse aux recommandations, un développeur d’intelligence d’affaires s’est mis d’accord sur Reddit que SQL peut devenir un cauchemar à maintenir sans un système approprié pour suivre les modifications de code.
Partageant son expérience dans une organisation de soins de santé, le développeur sous le pseudonyme de “Touvejs” a noté que certains scripts SQL peuvent s’exécuter sur des milliers de lignes. Ils peuvent également dater de plusieurs années et avoir été modifiés des dizaines de fois pour corriger des bogues fraîchement découverts ou pour incorporer de nouvelles fonctionnalités.
Sans fonctionnalité de contrôle de version, les choses se gâtent rapidement : “[A manual approach is] un système horrible. Modifications irréversibles. Versions précédentes perdues. Aucune idée des lignes exactes qui ont changé », écrit Touvejs.
Ce qui est clair, c’est qu’il n’y a pas un seul outil ou technique pour améliorer la situation, mais que reconnaître le problème et centraliser le code SQL est la façon de commencer. Un autre commentateur de Reddit suggère qu’une approche agressive fonctionne mieux.
“[My deployments drop] tout dans la base de données cible qui n’est pas sous contrôle de code source… Je souvent [annoy] développeurs lorsque je rejoins un projet parce que je continue à supprimer leurs trucs du [development] les serveurs. Mais finalement, ils apprennent à vérifier leur SQL, ou je leur retire leurs droits d’administrateur sur les bases de données », a-t-il écrit.
Il existe des outils pour aider les organisations à travailler avec les données et SQL, a expliqué un autre commentateur, et les entreprises intégreront éventuellement des domaines tels que l’ingénierie des données, l’entreposage des données et l’apprentissage automatique dans le pipeline de données pour faciliter l’ajout de nouvelles fonctionnalités.
Pour ceux qui réfléchissent encore à la gestion de leur SQL en tant que code, un autre commentateur avait ce point encourageant à ajouter : “[Consensus] Il semble que très peu d’entreprises traitent SQL comme du code orienté objet. Si votre entreprise le fait ; vous êtes en avance sur la courbe !
Paul Mah est le rédacteur en chef de DSAITrends. Ancien administrateur système, programmeur et professeur d’informatique, il aime écrire du code et de la prose. Vous pouvez le joindre au [email protected].
Crédit image : iStockphoto/die-phalanx
.