AFUP Day 2019
[:fr]La parole est aux speakers : Lætitia Avrot (AFUP Day 2019 Lyon)[:]
[:fr]Jusqu’à l’AFUP Day 2019 Lyon, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
La conférence
Les merveilles méconnues du SQLLe SQL est un langage très puissant. Si vous avez suivi les évolutions de la Cette conférence se focalisera sur ces nouvelles fonctionnalités, comment elles À la fin de cette conférence, vous devriez être capable d'utiliser toutes ces |
SupInfo 17/05/2019 15:40-16:20 |
De nombreuses développeuses et développeurs font peu de SQL et accèdent à leur base via des ORM. Quels sont les avantages à bien connaitre le SQL ?
Aujourd’hui, on voit de plus en plus de retours d’expériences de développeurs séniors expliquant que la ressource la plus utile qu’ils ont négligée dans leur apprentissage était le langage SQL. Ce qu’il faut bien comprendre, c’est que le langage SQL que 95% des développeurs connaissent est un sous-ensemble de ce que le SQL peut faire. En gros, les développeurs savent faire ce qu’on appelle des CRUD (Create, Read, Update, Delete) dans leurs expressions les plus simples. En n’utilisant pas toute la puissance du langage SQL (et du moteur du SGBDR), c’est-à-dire en n’utilisant le SQL uniquement pour récupérer des données sans les traiter, on laisse cette charge au programme dont ce n’est pas le travail. Au final, les performances ne sont pas au rendez-vous et personne n’est satisfait.
Ma vision des ORM est biaisée : on m’appelle quand ça ne marche pas… Je n’ai donc jamais vu un ORM utilisé correctement… Par contre, je peux dire une chose: mapper des objets sur des tables d’une base de données ne peut pas fonctionner. Les structures d’un programme sont créées pour gérer les données et les afficher. Le stockage en SGBDR est fait pour éviter au maximum la duplication des données. Ces buts différents font que les structures sont différentes. Ce qui a du sens, c’est de mapper des objets sur des relations, qui peuvent être un résultat de requête.
Un autre problème du SQL, c’est la généralisation du langage. Effectivement, il existe une norme SQL, mais comme toute norme, chaque moteur a développé sa propre manière de faire. Du coup, les ORM se reposent souvent sur un sous-ensemble du SQL qui fonctionne avec la majorité des SGBDR et là encore, on perd beaucoup à ne pas utiliser les spécificités du SGBDR choisi et on se retrouve, à nouveau, avec des problèmes de performances. Imaginez un développeur web qui décide de ne pas utiliser un seul hook dans son css pour avoir un code qui fonctionne sur tous les navigateurs ! C’est exactement le même problème.