Jusqu’au Forum PHP 2025, 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

SQL vs Les Préjugés Silence dans la salle ! La Cour Suprême du SQL est maintenant en session. Vous croyez tout connaître de SQL, n'est-ce pas ? Pourtant, SQL reste un mystère pour la plupart des développeurs, accusé de tous les maux : trop complexe, pas assez moderne, inutilement verbeux. Dans ce procès hors du commun, je vais défendre cette norme injustement méconnue en tant qu'experte PostgreSQL. Je présenterai les preuves irréfutables de son innocence face aux accusations les plus courantes. On dit que SQL est obsolète, pure diffamation ! On prétend que ces fonctionnalités avancées sont trop complexes pour être utiles, calomnie ! On affirme que SQL n'est pas adapté aux données modernes, fake news ! À travers démonstrations de code, cas d'utilisation réels et exemples concrets, je révélerai comment ces fonctionnalités peuvent transformer votre façon de travailler avec les données. Pas de catalogue interminable, mais des solutions pratiques à des problèmes que vous rencontrez tous les jours. À la fin de cette session, vous pourrez rendre votre verdict : coupable de complexité inutile ou solution élégante à vos défis techniques quotidiens ? Vous pouvez condamner SQL, mais l'histoire l'acquittera.

Adrien GALLOU - ABCDEF 09/10/2025 14:55-15:35

Quelle est l’erreur SQL la plus fréquente que tu vois chez les développeurs et développeuses ?

L’erreur la plus fréquente ? C’est de ne pas penser le modèle de données avant de coder ! 99% des fois où on m’appelle pour un problème de performance, c’est lié au datamodel. Et dans 95% de ces cas… devine quoi, il y a un ORM dans l’histoire 😅

Ce que je vois constamment : des colonnes ajoutées au petit bonheur la chance, des types de données choisis au jet de dé 20, aucune contrainte d’intégrité, et quand ça rame, hop ! On saupoudre des index partout comme du parmesan sur des pâtes. J’ai eu un client qui avait 15 index pour 10 colonnes sur une table qui mélangeait 5 ans d’historique avec les données courantes. Il utilisait date_fin IS NULL pour identifier les enregistrements actuels (si vous ne voyez pas le piège, voici les slides de ma conf sur NULL: https://l_avrot.gitlab.io/slides/null_20220525.html#/ . Il y a un quiz à la fin 😉).

Le plus frustrant ? Un modèle de données bien pensé ne devrait pas changer constamment, car il découle du métier, qui lui devrait être stable ! Si votre schéma bouge toutes les semaines, c’est peut-être que l’analyse métier n’a pas été assez poussée au départ.

PostgreSQL fait tout ce qu’il peut pour compenser nos erreurs de conception, c’est un moteur formidable. Mais même lui a ses limites. Le jour du pic de charge, tout s’effondre.

La solution ? Prendre le temps de dessiner son modèle avant d’écrire la première ligne de code et partager ce modèle avec le métier pour s’assurer qu’on a bien compris. Ça évite des semaines de debug et des nuits blanches. Promis, votre futur vous remerciera !

Quelles sont les nouveautés de PostgreSQL que tu attends avec impatience ?

PostgreSQL 18 arrive avec des pépites !

D’abord, les colonnes générées virtuelles par défaut ! Fini le stockage inutile de données calculées qui prennent de la place sur le disque. Ces colonnes se calculent à la lecture, pas à l’écriture. C’est parfait pour des champs comme « nom_complet » basé sur prénom + nom, ou « prix_ttc » calculé depuis le prix HT. Ça va alléger l’écriture des requêtes SQL !

Ensuite, une amélioration discrète mais géniale des index btree : le skip scan. Enfin ! Si j’ai un index sur (statut, date_creation) et que ma requête cherche seulement sur date_creation, PostgreSQL pourra utiliser l’index en « sautant » les valeurs de statut. Plus besoin de créer 15 index pour couvrir toutes les combinaisons possibles 😅

Et puis, le monitoring renforcé partout : temps passé en VACUUM/ANALYZE, statistiques I/O par backend, détails sur les buffers… C’est Noël pour nous qui debuggons les performances ! Ça va faciliter le diagnostic et éviter les « ça rame mais on ne sait pas pourquoi ».

Par contre, les UUID v7… bof. Je n’ai toujours pas trouvé de vrai use case pour stocker des UUID en base. Un bon vieux GENERATED ALWAYS AS IDENTITY fait très bien l’affaire dans 100% des cas ! D’ailleurs, je maintiens que les ID sont internes à la base et ne devraient pas en sortir. L’application peut les utiliser pour les jointures, mais devrait s’appuyer sur les clés naturelles. Si vous n’êtes pas d’accord, on peut avoir une discussion passionnante autour d’un verre au Forum PHP ! 🍻

Ces améliorations montrent que PostgreSQL continue d’évoluer intelligemment : moins de maintenance manuelle, plus de flexibilité, meilleur diagnostic. Que demander de plus ?

Et surtout, n’oubliez pas que PostgreSQL, c’est une communauté ouverte ! Si une de ces nouveautés vous intrigue, ou si vous avez des idées d’améliorations, n’hésitez pas à contribuer. Ça peut commencer simplement : tester les bêtas, reporter des bugs, améliorer la documentation, ou même proposer des petits patches. La communauté PostgreSQL est accueillante et toujours ravie d’accueillir de nouveaux contributeurs, quel que soit votre niveau. Qui sait, peut-être que votre nom sera cité dans la release note de PostgreSQL 19 ! 😉

Tu évoques le préjugé du SQL considéré comme obsolète. C’est également un préjugé récurrent et de longue date pour PHP. Même combat pour les deux langages ?

Absolument ! Et c’est exactement le même schéma qui se répète sans arrêt dans notre industrie.

D’abord, l’open source est immortel parce que n’importe lequel des 8 milliards d’êtres humains peut le faire vivre, juste pour le fun ! Regardez GIMP : abandonné par ses créateurs dans les années 90, mais toujours là 25 ans après grâce à une communauté passionnée. C’est ça, la magie de l’open source !

Ensuite, on disait que COBOL était mort lol ! Sauf que… 40% des banques l’utilisent encore comme technologie centrale, il gère 95% des transactions ATM et traite 3 trillions de dollars par jour. Pas mal pour un « mort » ! 😅

On a annoncé la mort du SQL dans les années 2000 avec le NoSQL (qui est devenu « Not Only SQL » quand ils se sont rendus compte de leur connerie). Maintenant, on annonce à nouveau la mort du SQL avec l’IA…

Je vais vous dire un secret : l’IT, ce n’est pas le monde de la mode. On ne choisit pas une techno pour faire pâlir de jalousie la voisine. On la choisit parce qu’elle convient au besoin et qu’elle est stable.

PHP et SQL ont un truc en commun : ils font le boulot, point. Ils ne sont peut-être pas « sexy » aux yeux des développeurs qui courent après le dernier framework à la mode, mais ils alimentent une grande partie du web et des bases de données mondiales.

Alors oui, même combat ! Ces technos survivront à leurs fossoyeurs, comme elles l’ont toujours fait. Et dans 10 ans, on entendra encore « PHP/SQL est mort » pendant qu’ils continueront tranquillement à faire tourner la moitié d’Internet ! 🤷‍♀️

Une conférence présentée par

Lætitia AVROT

Lætitia Avrot est une figure influente dans le monde de PostgreSQL. Elle est la fondatrice de Postgres Women et une contributrice reconnue du projet PostgreSQL. Lætitia a découvert Postgres en 2007 et compte plus de 20 ans d'expérience en tant que professionnelle de l'informatique, spécialisée dans PostgreSQL et la sécurité des bases de données. Elle intervient comme experte technique et consultante pour les organisations implémentant des solutions PostgreSQL à travers l'Europe. Lætitia partage également son expertise en tant que chargée de cours à temps partiel à l'Université de Lyon, où elle enseigne PostgreSQL depuis 10 ans. Son leadership et son dévouement ont fait d'elle une professionnelle respectée au sein de la communauté PostgreSQL mondiale.

Autres interviews

• La parole est aux speakers : Felix Eymonot
• La parole est aux speakers : Houleymatou Baldé
• La parole est aux speakers : Gina Banyard
• La parole est aux speakers : Maxime Huran
• La parole est aux speakers : Clément Talleu
• La parole est aux speakers : Jori Stein
• La parole est aux speakers : Baptiste Langlade
• La parole est aux speakers : Thibaut Soulcié
• La parole est aux speakers : Olivier Mairet
• La parole est aux speakers : Amaury Bouchard
• La parole est aux speakers : François Zaninotto
• La parole est aux speakers : Damien Alexandre
• La parole est aux speakers : Louis Vareille