Une base de données qui n'est qu'un fichier change tout

DB Browser for SQLite est un outil graphique libre pour les bases SQLite, disponible sous Windows, macOS et Linux, et sa conception découle directement de celle de ce qu'il ouvre. SQLite n'est pas un serveur. Il n'y a pas de processus auquel se connecter, pas de compte, pas de port, pas de démon qui tourne discrètement ; une base de données est un fichier posé dans un dossier, et le programme qu'on pointe dessus porte l'entière responsabilité de la structure comme du contenu.

C'est cette propriété qui met SQLite dans tant d'applications — téléphones, navigateurs, applications de notes, logiciels de bureau de toute sorte — et qui rend un outil pour l'inspecter réellement utile et pas seulement pratique. Quand quelque chose se passe mal dans une application qui garde son état dans un fichier local, c'est là qu'on peut regarder cet état. Quand un projet a besoin d'un peu de données structurées et d'aucun serveur, c'est là que le fichier prend forme.

La métaphore du tableur fait un vrai travail

Les enregistrements s'affichent dans une grille et se modifient sur place, à la manière d'un tableur, et c'est plus qu'un geste aimable envers ceux qui ne savent pas écrire de SQL. Une grille rend la forme des données visible : combien de lignes, quelles colonnes sont presque toujours vides, quelles valeurs se répètent d'une manière qui suggère une table manquante. La plupart des erreurs de schéma ne sont pas commises par des gens incapables d'écrire une requête, mais par des gens qui n'ont jamais regardé les données.

La même grille est aussi l'endroit où un certain type de dégât se produit. Modifier des cellules directement est rapide, et l'on oublie facilement qu'une valeur dans une grille est une ligne dans une table dont autre chose peut dépendre. Parcourir, trier et chercher avant de changer quoi que ce soit — regarder ce qui est réellement là plutôt que ce que le schéma dit qu'il devrait y avoir — est l'habitude qui empêche un éditeur direct de devenir un accident direct.

Changer un schéma n'est jamais aussi simple qu'il y paraît

Créer des tables, définir et modifier leurs colonnes, les supprimer, gérer les index est offert comme un ensemble d'opérations ordinaires, et l'important est de comprendre qu'en dessous elles ne le sont pas du tout. Les moteurs relationnels diffèrent par ce qu'ils peuvent modifier sur place, et l'approche de SQLite pour beaucoup de changements de schéma consiste essentiellement à construire une nouvelle table, y copier les données, supprimer l'ancienne et renommer la nouvelle. Un outil graphique cache cette séquence, ce qui aide, et signifie aussi que la copie se fait sur de vraies données sans personne pour regarder.

Les index méritent le même respect, pour une autre raison. Un index est une promesse sur la manière dont les requêtes seront servies ; l'ajouter à une grande table prend du temps et de l'espace sans rien ajouter de visible ; le retirer reste invisible jusqu'à ce qu'une requête devienne lente trois semaines plus tard. Un outil qui fait des deux un clic les a rendus bon marché à exécuter et pas du tout moins chers à penser.

Un éditeur SQL dont le résultat arrive tout de suite

Écrire une requête et voir son résultat dans la même fenêtre est la plus courte boucle de retour possible, et cela change la façon dont on apprend SQL. L'ancienne disposition — écrire ici, exécuter là, lire une erreur, deviner — transforme une faute de syntaxe en mystère. Ici, l'instruction et sa conséquence sont côte à côte, et c'est ainsi que la langue s'absorbe vraiment : non en mémorisant la grammaire, mais en voyant ce qu'une clause fait à un jeu de résultats.

C'est aussi la manière honnête de travailler. Une requête qui s'exécute sans erreur et ne renvoie rien, ou qui renvoie quatre mille lignes là où une était attendue, enseigne en cinq secondes plus qu'une page de documentation. La valeur de l'outil n'est pas d'écrire la requête à votre place ; elle est de ne jamais vous faire attendre pour découvrir que vous vous trompiez.

CSV dedans, CSV et SQL dehors

Importer depuis un CSV et exporter vers un CSV ou un script d'instructions SQL est la fonction la moins spectaculaire de la liste et celle qui a le plus de chances de servir un mauvais jour. C'est aussi là que se trouvent les angles. Un fichier CSV n'a pas de types : tout y est du texte, et savoir si une colonne de chiffres devient un nombre ou reste une chaîne est une décision prise à l'import qui sera discrètement fausse plus tard. Les encodages causent la même classe de problème, et un format de date ambigu dans le fichier source sera résolu en devnant.

L'export vers un script SQL est la moitié sous-estimée. Il transforme une base en fichier texte qui peut être relu, versionné et rejoué, ce qui est la différence entre un bloc binaire que personne ne peut inspecter et un changement dont on peut discuter. Pour qui garde les données initiales d'une petite application dans un gestionnaire de versions, cet export est toute la raison de l'installation.

Le chiffrement est une promesse à lame

Pouvoir ajouter, changer ou retirer un chiffrement SQLCipher sur un fichier de base est une capacité sérieuse, et elle vient avec la propriété qui rend le chiffrement désirable : sans la phrase secrète, le fichier n'est pas une base de données, c'est du bruit. C'est le but, et c'est aussi le risque. Il n'y a pas de chemin de récupération, pas de support, pas de réinitialisation ; une phrase oubliée équivaut à un fichier supprimé, et la suppression est plus définitive car il n'y a rien à récupérer.

La conséquence pratique est procédurale plutôt que technique : le chiffrement s'applique de préférence quand la phrase secrète est enregistrée ailleurs en même temps, et se teste de préférence sur une copie avant d'être appliqué à la seule version qui existe.

Un projet avec une histoire a une réputation

L'outil a commencé comme compagnon d'un autre navigateur de bases, écrit par un développeur isolé, et est devenu un projet autonome à travers plusieurs renommages et des années de contributions communautaires. Cette origine mérite d'être mentionnée car elle explique une qualité difficile à contrefaire : l'ensemble des fonctions reflète ce dont les gens avaient réellement besoin en travaillant avec ces fichiers, non ce qu'un plan produit imaginait. Le libre n'est pas ici une étiquette de licence ; c'est la raison pour laquelle l'outil a survécu à plusieurs des applications dont il sert à inspecter les données.

Là où il trouve sa place

Il convient au développeur qui doit voir ce qu'une application a réellement écrit, à l'analyste à qui l'on tend un fichier et qui doit en comprendre le contenu avant de lui faire confiance, à la salle de cours où l'on enseigne SQL et où un résultat visible compte, et à la machine hors ligne où une base locale est la seule donnée disponible. Ce n'est pas une console d'administration de serveur, il n'est pas conçu pour de nombreux écrivains simultanés, et il ne prétend pas remplacer la ligne de commande du moteur quand la précision compte. Pour le fichier dans le dossier, il est proche de l'idéal.