Faragiri

Apprendre les bases de donnéesla programmation

Ce qu'une base promet après une coupure, ce qu'un index coûte à chaque écriture, et le réglage français qui décide qui votre formulaire de recherche trouve.

6Sections
7Min de lecture
2Profondeur

Un index, trois effets

Poser un index, et deux des trois autres le paient

Trois propriétés de la même table, et aucun index n'est gratuit : ce que la lecture gagne, l'écriture et le disque le rendent.

  • Des lectures achetées par une écriture à chaque changement
  • La copie doit bien vivre quelque part
  • L'échange que personne ne fait exprès
  • Vitesse de lecture
  • Vitesse d'écriture
  • Stockage
  • Vitesse de lecture9 400 lignes parcourues deviennent 260 lues, et 38 secondes deviennent 60 millisecondes
  • Vitesse d'écritureChaque insertion et chaque mise à jour écrit désormais deux fois, dans la ligne puis dans la copie
  • StockageUn double trié de la colonne, gardé sur le disque et gardé à jour

Elle ne dit pas à partir de combien d'index c'est trop, parce que la réponse tient entièrement au rapport des lectures aux écritures sur cette table-là. Une table lue une fois par mois et écrite une fois par seconde n'en veut aucun.

Fatou Sarr a repris le fichier des 9 400 licenciés d'un comité départemental de handball à Saint-Denis de La Réunion. Le formulaire de recherche du secrétariat trouve « Lévêque » quand on tape « Leveque ». Le même formulaire, sur le serveur monté six mois plus tard, ne trouve rien. Le code est identique, la donnée est identique, et aucune des deux bases n'a de défaut.

Ce qui diffère porte un nom que presque personne n'apprend : la collation, c'est-à-dire la règle qui décide quand deux chaînes sont égales. Sur MySQL 8, la collation par défaut de utf8mb4 est utf8mb4_0900_ai_ci, où ai veut dire insensible aux accents et ci insensible à la casse. PostgreSQL ne fait rien de tel sans qu'on le lui demande.

Une base n'est pas un endroit où poser des choses. C'est un jeu de promesses sur ce qui sera encore vrai après une coupure, et un jeu d'arbitrages sur ce qui ira vite. Toutes les rubriques rangées ici sont l'un ou l'autre, et la moitié utile du sujet consiste à savoir lequel des deux on est en train de payer.

La collation décide qui votre recherche trouve

Le réglage se pose au niveau du serveur, de la base, de la table ou de la colonne, et le plus précis l'emporte. Il décide trois choses d'un coup : quels caractères sont égaux, ce que vaut la casse, et dans quel ordre une clause de tri range les lignes. C'est le même réglage qui remet Élise et Émile à leur place alphabétique là où un tri par code les envoyait après Zoé, et c'est la raison pour laquelle les bases de la programmation se termine en pointant ici.

  • SELECT 'Leveque' = 'Lévêque' COLLATE utf8mb4_0900_ai_ci; rend 1
  • SELECT 'Leveque' = 'Lévêque' COLLATE utf8mb4_0900_as_cs; rend 0
  • ORDER BY nom COLLATE utf8mb4_0900_ai_ci rend Ahmed, Élise, Nour, Zoé
  • CREATE INDEX ON licencies (derniere_visite); est la ligne de la section suivante
  • EXPLAIN SELECT ... dit ce que la base compte faire avant qu'elle le fasse

Le confort a un prix. Une comparaison insensible aux accents ne peut plus servir de contrainte fine : sur MySQL, « Dupont » et « Dupônt » entrent en collision dans un index unique, ce qui est presque toujours ce qu'on veut pour un annuaire et jamais ce qu'on veut pour un identifiant. La règle qui tient est de choisir la collation colonne par colonne, insensible aux accents sur ce que des gens cherchent, binaire sur ce que la machine compare.

La ligne qui a retiré trente-huit secondes

Le rapport mensuel du comité liste les licenciés dont la visite médicale a plus d'un an. Sans aide, la base n'a qu'une façon de répondre, lire les 9 400 lignes et regarder chaque date. Un index est une seconde copie de la colonne, tenue triée, et avec elle la base saute directement à la date charnière et ne lit que ce qui est au-delà. Le rapport prenait 38 secondes, il en prend 60 millisecondes, et pas un caractère de la requête n'a changé.

Si ce n'est pas gratuit, et si une base n'indexe pas tout d'office, c'est que la copie doit rester vraie. Chaque insertion et chaque mise à jour de cette colonne écrit désormais deux fois, une fois dans la ligne et une fois dans l'index. Sur une table lue sans arrêt et écrite rarement, l'échange est excellent. Sur une table qui prend une écriture par seconde et se lit une fois par mois, il est à l'envers, et l'index devient un impôt payé toute la journée pour une économie encaissée une fois.

La commande qui met fin à la discussion est EXPLAIN, qui demande à la base ce qu'elle compte faire avant qu'elle le fasse. Elle répond par un plan : un parcours séquentiel de 9 400 lignes, ou un parcours d'index de 260. Lire cette sortie est la compétence la plus transportable du sujet, et c'est à cela que sert SQL.

Trois faits qui produisent la plupart des réponses fausses

Le premier ne rend rien et ne dit rien. NULL n'est pas égal à NULL, donc IS NULL est le seul test qui marche. NULL ne veut dire ni zéro ni vide, il veut dire inconnu, et deux inconnus ne peuvent pas être déclarés égaux, donc une comparaison d'égalité avec NULL n'est pas une erreur et ne correspond à aucune ligne. Fatou avait exactement cela dans une première version, qui annonçait tranquillement que tout le monde était à jour.

Le deuxième bloque la machine. Une jointure sans condition ON, c'est chaque ligne contre chaque ligne. Joindre 9 400 licenciés à 62 clubs sans dire comment ils se rattachent demande 582 800 lignes, et la base le fera, parce que la demande est légale. Le symptôme n'est pas un message d'erreur, c'est une requête qui ne revient pas.

Le troisième compte quand quelque chose s'arrête à mi-chemin. Une transaction, c'est tout ou rien. Transférer un licencié d'un club à un autre fait deux écritures, et une coupure entre les deux laisse un licencié sans club. Enveloppées dans BEGIN et COMMIT, ou bien les deux arrivent, ou bien aucune, et il n'existe aucun état intermédiaire que quiconque puisse observer. C'est la promesse que le mot base désigne réellement, et c'est pourquoi la conception d'une base passe avant tout outillage.

Un quatrième fait tient à la monnaie et il est plus souvent raté en France qu'ailleurs, parce que les montants y arrivent d'un tableur. Une colonne de montants se déclare NUMERIC et jamais un flottant. Une cotisation de 34,50 € rangée dans un flottant s'additionne trois mille fois avec une dérive de quelques centimes, invisible ligne à ligne et visible au total. NUMERIC tient le centime exactement, et coûte une vitesse que personne ne remarquera jamais sur un tableau de cotisations.

L'ordre

Quatre barreaux, et chacun devient invisible si l'on a commencé au-dessus

Presque tout le monde commence au troisième, parce que c'est celui qui porte un nom sur une offre d'emploi.

  1. 04L'autre formeDocuments et clés, quand une ligne fixe est vraiment le mauvais contenant.Sans les trois premiers, c'est une devinette
  2. 03Le moteurQuel produit, quel dialecte, et ce qu'il fait sous une coupure.Choisi avant votre arrivée
  3. 02La formeQuelles sont les tables, ce qui est unique, ce qui n'a pas le droit de manquer, et quelle collation compare.Sautée, aucun index ne vous sauve
  4. 01Le langagePoser les questions directement, et lire le plan que la base rend en réponse.Sauté, le mapping reste opaque

Elle ne dit rien du temps que chaque barreau demande. Le premier se prend en un week-end. Le deuxième met des années, parce qu'il ne s'apprend que sur des schémas qu'on a soi-même eu tort d'écrire.

L'ordre, et ce que coûte de le sauter

L'ordre qui marche est le langage, puis la forme, puis le moteur. Presque personne ne le prend ainsi, parce que le moteur est ce qu'une offre d'emploi nomme et que la forme n'est nommée par rien.

Pris à l'envers, l'échec a une signature. Quelqu'un apprend un mapping objet avant SQL, obtient une application qui marche, puis rencontre une page lente sur laquelle il ne peut pas raisonner, parce que la couche qui écrit les requêtes à sa place est devenue celle qui cache ce qui est lent. Le mapping n'est pas le problème et les données depuis le code sont un vrai sujet. Cette couche n'est illisible que pour qui n'a jamais vu ce qu'elle produit.

Où l'on cale

Le blocage est de choisir une base avant de connaître la forme de la donnée, et le choix se fait d'ordinaire sur ce qu'on a lu en dernier. La position honnête est que le NoSQL répond à une vraie question, et que la question est de savoir si la donnée a une forme fixe et des relations qui comptent. Celle de Fatou en a : un licencié appartient à un club, une rencontre appartient à deux, et chaque rapport qu'elle écrit est une jointure.

Le second blocage a une moitié française. On traite la base comme le service de quelqu'un d'autre jusqu'au jour où une page est lente, et l'on découvre que la réparation n'était pas dans le code de l'application. L'autre moitié est qu'une base n'oublie rien toute seule : une durée de conservation qui n'existe que dans un document, et pas sous la forme d'une suppression programmée que quelqu'un a écrite, n'est pas une durée de conservation. C'est du SQL et une tâche planifiée, et c'est la même question de permission que sur le développement web, posée cette fois sur ce qu'on garde plutôt que sur ce qu'on dépose.

Ce qu'on ouvre en 2026

SQLite est le bon endroit pour apprendre et, de plus en plus, le bon endroit pour livrer. C'est un seul fichier, il ne demande aucun serveur, il est dans le domaine public, et il a remplacé l'habitude d'inventer un format de fichier puis d'en écrire l'analyseur. Un comité de la taille de celui de Fatou pourrait tourner dessus indéfiniment.

PostgreSQL est le choix par défaut quand un serveur se justifie, il est gratuit et ouvert, et il a pris cette place à MySQL au cours de la décennie écoulée. Les deux comprennent EXPLAIN, les deux tiennent les transactions correctement, et le SQL enseigné ici passe de l'un à l'autre au prix de quelques différences de dialecte. La collation en est une, et c'est la plus visible en français : sur PostgreSQL, la comparaison insensible aux accents demande l'extension unaccent ou une collation ICU déclarée, et rien n'arrive gratuitement. Lequel des deux atterrit sur un projet se décide d'ordinaire avant qu'on arrive, ce qui est la raison d'être des moteurs de base de données.

Reste la question qui arrive quand une seule machine ne suffit plus à tenir la chose. Les promesses posées au début de cette page se renégocient alors une par une, délibérément, et la première décision concrète n'est plus un schéma mais un endroit et une procédure de retour, ce dont s'occupe la mise en production.

À côté

Au-dessus