[: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

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.

MySQL tente de rattraper son retard en terme de fonctionnalités sur PostgreSQL. Penses-tu qu’ils ont fini par combler leurs lacunes ou PostgreSQL conserve toujours une marge d’avance sur la concurrence ?

Cette question est assez drôle, car lorsque j’ai commencé Postgres, vers 2007, c’était MySQL qui était en avance sur Postgres en terme de fonctionnalités. Mais c’est une question de philosophie. PostgreSQL a toujours mis en avant la stabilité par rapport aux fonctionnalités. Ce qui a permis au projet de construire sereinement les fonctionnalités sur des bases solides, mais beaucoup plus lentement. Au contraire, mySQL a mis en avant les fonctionnalités. Je ne me prononcerai pas sur la stabilité du moteur parce que je ne le connais pas, mais je peux citer un exemple sur lequel on voit cette philosophie. Pour renforcer certaines contraintes d’intégrité, la norme SQL prévoit des `check constraints`. Cela permet pour une colonne qui stocke des prix de s’assurer que ceux-ci sont toujours positifs, par exemple. Cette fonctionnalité a été ajoutée à MySQL, dans le sens où la syntaxe SQL permet de déclarer une telle contrainte. Cependant, jusqu’à très récemment (avant MySQL 8.0), la contrainte indiquée n’était jamais vérifiée. Autre exemple, chez PostgreSQL, 98% des bugs sont corrigés dans la journée… Une nouvelle version ne sortira jamais tant qu’il existe des bugs connus non corrigés.

On parle de plus en plus de PostgreSQL dans notre écosystème « PHP ». Est-ce une tendance que tu rencontres aussi avec d’autres technologies ?

Je crois qu’on peut dire qu’on parle de plus en plus de PostgreSQL. Pour beaucoup, le fait d’utiliser un outil open source semble être un risque. J’entends souvent dire qu’il n’y a pas de support. Au contraire, plusieurs sociétés font du support pour Postgres donc si vous n’êtes pas contents du prestataire, vous pouvez en changer, vous n’êtes pas captifs! De plus, une manière simple d’évaluer la qualité d’un outil open source est d’aller lire son code. Il suffit de choisir n’importe quel fichier, de le lire (en étant concentré, quand même) et de voir si on le comprend (avec l’aide des commentaires).
Bien sûr, la stabilité de PostgreSQL (99,999% d’uptime) et le fait que les éditeurs privés fixent des prix parfois exorbitants aident beaucoup à l’adoption de Postgres et c’est tant mieux!

Une conférence présentée par

Lætitia AVROT

Lætitia est consultante et formatrice PostgreSQL pour Loxodata à Lyon. Elle a commencé à travailler sur PostgreSQL en 2007. Rapidement, elle a du apprendre aussi l'administration Oracle et SQL Server. Lors de ses différentes expériences, elle a pu travailler sur des projets à fortes contraintes de haute disponibilité et de forte charge, des incidents de prod, des PRA, des données géographiques...

Autres interviews

• [:fr]La parole est aux speakers : Aleth Gueguen (AFUP Day 2019 Rennes)[:]
• [:fr]La parole est aux speakers : Yvonnick Frin et Benjamin Cavy (AFUP Day 2019 Rennes)[:]
• [:fr]La parole est aux speakers : Kévin Dunglas (AFUP Day 2019 Lille)[:]
• [:fr]La parole est aux speakers : Sarah Haïm-Lubczanski (AFUP Day 2019 Rennes)[:]
• [:fr]La parole est aux speakers : Maxime Huran (AFUP Day 2019 Lille)[:]
• [:fr]La parole est aux speakers : Gaël Crispyn (AFUP Day 2019 Lille)[:]
• [:fr]La parole est aux speakers : Benoit Jacquemont (AFUP Day 2019 Rennes)[:]
• [:fr]La parole est aux speakers : Rodrigue Villetard (AFUP Day 2019 Lille)[:]
• [:fr]La parole est aux speakers : Frédéric Hardy (AFUP Day 2019 Lyon)[:]
• [:fr]La parole est aux speakers : Fabien Féat (AFUP Day 2019 Rennes)[:]
• [:fr]La parole est aux speakers : Samuel Roze (AFUP Day 2019 Lille)[:]
• [:fr]La parole est aux speakers : Antoine Deprez et Brice Taillardat (AFUP Day 2019 Rennes)[:]
• [:fr]La parole est aux speakers : Stéphane Hulard (AFUP Day 2019 Lyon)[:]
• [:fr]La parole est aux speakers : Kévin Verschaeve (AFUP Day 2019 Lille)[:]
• [:fr]La parole est aux speakers : Gabriel Pillet (AFUP Day 2019 Lyon)[:]
• [:fr]La parole est aux speakers : Grégoire Hébert (AFUP Day 2019 Lille)[:]
• [:fr]La parole est aux speakers : Vincent Lainé (AFUP Day 2019 Rennes)[:]
• [:fr]La parole est aux speakers : Freek Van Der Herten (AFUP Day 2019 Lille)[:]
• [:fr]La parole est aux speakers : Julien Deniau (AFUP Day 2019 Lyon)[:]
• [:fr]La parole est aux speakers : Frédéric Bouchery (AFUP Day 2019 Rennes)[:]
• [:fr]La parole est aux speakers : Julien Pauli (AFUP Day 2019 Lille)[:]
• [:fr]La parole est aux speakers : Alex Rock (AFUP Day 2019 Lyon)[:]
• [:fr]La parole est aux speakers : Damien Alexandre (AFUP Day 2019 Rennes)[:]