[:fr]La parole est aux speakers : Lætitia AVROT[:]

[:fr]Jusqu’à l’AFUP Day 2020, 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 visiteurs et visiteuses de l’AFUP Day 2019 Lyon ont eu la chance d’assister à une de tes confs. Tu réédites l’exercice cette année. Quels retours as-tu eus suite à cette journée et as-tu des attentes à propos de l’édition 2020 ?

Avant de postuler pour AFUP Day 2019, j’étais morte de peur à l’idée d’aller parler dans une conférence de développeurs. Les conférences auxquelles je participe sont très orientées bases de données et, comme à chaque fois qu’on sort de sa zone de confort, la peur est là.
Les retours ont été très positifs dans le sens où j’avais visé juste: ces trésors du SQL étaient bien méconnus de la plupart des participant·e·s, mais je me suis aussi rendue compte que cette conférence aurait gagné à aborder moins de points mais plus en détails. J’ai tenu compte de cet aspect lorsque j’ai redonné cette conférence.
Cette année, la conférence qui a été choisie va se concentrer sur un des fondamentaux des SGBD relationnels: l’Isolation, le fameux I des propriétés ACID.

Peux-tu nous citer les différents niveaux d’isolation possibles afin de nous mettre l’eau à la bouche ?

Il existe dans la norme SQL 4 niveaux d’isolation des transactions: le READ UNCOMMITTED, le READ COMMITTED, le REPEATABLE READ et le SERIALIZABLE. Pour la plupart des SGBDR, le niveau par défaut est READ COMMITTED, qui est un bon compromis entre la performance et l’interaction entre les transactions, mais cela implique des conséquences pas toujours connues qui peuvent poser problème. Le niveau d’isolation peut être changé pour une transaction seulement et peut vraiment éviter d’ajouter des sur-couches aux applications.

Tu vas nous parler d’un concept établi il y a près de 40 ans et qui est pourtant mal connu ou mal utilisé. Penses-tu qu’il s’agit d’un défaut de formation, d’outillage parmi les développeurs·euses ou tout simplement que c’est lié au décalage de métier entre un·e développeur·euse et un·e administrateur·trice de base de données ?

Je pense qu’effectivement les formations se concentrent un peu trop sur les langages de développement alors que l’informatique est beaucoup plus riche que ça ! Il n’y a pas (en France ou dans le monde) de formation initiale d’administrateur•trice de bases de données, c’est un métier qu’on apprend directement en production avec les risques que cela implique… Il y a aussi toute une génération de développeurs·euses qui se reposent sur l’ORM pour écrire leurs requêtes (voire pour modéliser les bases de données). Je pense que c’est une mauvaise pratique qui engendre des gros soucis de performance ou d’intégrité des données, mais d’un autre côté, je ne suis appelée par les clients que lorsque ça va mal !

Une conférence présentée par

Lætitia AVROT

Lætitia Avrot est experte PostgreSQL chez EnterpriseDB. Elle est co-fondatrice du mouvement Postgres Women, membre du Postgres Advocacy Group et membre du Postgres Funds Group. Elle a aussi été pendant un an membre du comité du Code de Conduite de la communauté PostgreSQL. Elle a écrit plusieurs patchs pour le projet PostgreSQL et donne régulièrement des conférences dans des événements communautaires.

Autres interviews

[:]