Un autre principe de Winand : le développeur est celui qui sait comment les données sont utilisées. Il est à la fois le premier utilisateur des index et celui qui doit savoir pointer ceux qui manquent. (Et je confirme qu’à part certaines évidences ou contraintes techniques, il est difficile de savoir comment optimiser une base quand on n’a aucune idée de la manière dont elle sera utilisée, des critères primordiaux des utilisateurs, de la fréquence d’utilisation de telle ou telle donnée. Quant aux DBAs j’ai constaté qu’hors problème sérieux ils étaient assez peu proactifs. De plus, si certains étaient ouverts à l’ajout d’index quand on le justifiait, d’autres voyaient ça avec une franche hostilité [1].)

Le bien

Bref, il y a là-dedans tout ce que j'aurais voulu savoir quand je tapais du SQL au kilomètre. À cette époque (et après) j’ai acquis pas mal de réflexes pour obliger Oracle à choisir tel chemin et pas un autre. Mais il est toujours agréable et instructif de voir réexprimés proprement des concepts appris sur le tas, expliqué des habitudes prises par imitation et validé des réflexes. En général, je me suis retrouvé conforté dans mes habitudes, et encouragé à creuser un peu plus l’existant ou le juste-effleuré (index couvrants notamment).

Contrairement à nombre de livres sur les bases de données, il ne se spécialise pas sur une seule, mais parle des quatre principales : Oracle, SQL Server, PostgreSQL, MySQL. J’aurais bien aimé en voir d’autres (comme SQLite, même s’il est limité, ou Sybase) mais on ne peut pas tout avoir. Les différences entre les bases sont une part importante de la culture informatique. MySQL apparaît souvent comme le mauvais élève.

Le livre se concentre presque exclusivement sur les index B-tree classiques, de loin les plus courants. Il part des bases puis dissèque les méthodes d’utilisation (hash, merge...), ou leur utilisation dans différents contextes, dont les résultats partiels, ou encore l’impact sur les tris. La nécessité et les limites des bind dans les requêtes répétées sont abordés, tout comme les dégâts que peuvent faire des ORM comme Hibernate.

Le moins bien

Il y a juste une mention des index bitmaps pour dire qu’il sont réservés aux datawarehouses à cause de leur coût élevé en mise à jour [2]. Winand ne dit pas du bien des tables organisées en index comme cela semble courant sous SQL Server (les autres index seraient plombés par cette structure) mais un commentateur sur Amazon lève une objection (mais il travaille chez Microsoft, à moins que ce soit un homonyme).

Les requêtes d’exemple sont assez simples pour la compréhension, mais finalement je me demande encore quelle politique adopter pour optimiser des requêtes de dix tables, en décisionnel ou pas — il n’y a sans doute pas de recette miracle, il faut voir ce que pond l’optimiseur.

Où

Le livre en allemand (la VO ?), anglais (que j’ai lu) ou français est disponible sur Amazon, et hélas uniquement là, sous forme papier du moins. Cependant l’essentiel semble accessible depuis le site.

Mise à jour de 2020 : je continue de conseiller ce livre en formation à tous ceux qui doivent parler à une base de données, DBA comme développeurs — surtout les développeurs.

Notes

[1] Mais sous SAP R/3 la logique normale n’a pas cours, voir ma vieille série sur le sujet, là, là et là, commentaires compris.

[2] Et, ajouterai-je, du coût de la licence Oracle Enterprise nécessaire.