Le problème est rarement une seule base

Quiconque travaille avec des données finit par en rassembler une petite collection. Un système de production sur un moteur, une copie locale sur un autre, un projet client sur un troisième, plus un tableur reçu de quelqu'un qu'il faut charger quelque part avant de pouvoir l'interroger. La réponse habituelle est un client différent par moteur, chacun avec ses raccourcis et sa propre idée de l'endroit où vont les résultats. DBeaver Community prend le chemin inverse : une seule application qui parle à tous, si bien que les réflexes acquis sur une base se transfèrent à la suivante.

Une fenêtre organisée comme une base

La fenêtre principale suit la logique du travail. D'un côté se trouve un navigateur qui montre connexions, schémas et tables sous forme d'arbre, de sorte que la forme des données est visible sans requête. Au centre, l'éditeur SQL. En dessous ou à côté, le volet de résultats. Passer de l'un à l'autre est permanent pendant le travail, et les garder ensemble signifie que la réponse apparaît à côté de la question plutôt que dans une autre fenêtre qu'il faut d'abord disposer. Les menus contextuels et une barre d'outils portent les opérations les plus répétées : ouvrir une table, filtrer des lignes, modifier une valeur, supprimer des données qui n'ont rien à faire là.

Relationnel et non relationnel au même endroit

La liste des moteurs pris en charge est la raison pour laquelle beaucoup l'installent. Les systèmes relationnels comme MySQL, PostgreSQL et Oracle sont couverts, tout comme les stockages non relationnels tels que MongoDB et Cassandra. Ce mélange compte en pratique, car les systèmes modernes restent rarement dans une seule catégorie. Une migration lit dans l'ancien moteur et écrit dans le nouveau ; une revue de conception compare un schéma relationnel avec un stockage qui accueillera la partie souple. Pouvoir atteindre les deux depuis un même client transforme ces tâches en une paire d'onglets au lieu d'une séance de changements de contexte.

Un éditeur pour ceux qui écrivent des requêtes toute la journée

La coloration syntaxique est le minimum et elle est là. Plus utile est une complétion qui connaît le schéma, si bien que les noms de tables et de colonnes arrivent sans avoir été mémorisés. Le formatage remet droit une requête qui a poussé de travers pendant le débogage, ce qui la rend lisible le lendemain matin. Chaque moteur a son dialecte, et l'éditeur suit celui en cours au lieu de prétendre qu'ils sont interchangeables. Pour qui passe ses journées en requêtes, ce n'est pas un luxe : c'est la différence entre écrire une fois et réécrire parce qu'un nom était faux.

Faire entrer et sortir les données

C'est sur l'import et l'export qu'un outil de base gagne sa place ou devient une corvée. DBeaver lit les formats CSV et tableur et les réécrit, en assurant la correspondance des colonnes au passage. Cela couvre les deux directions que prennent les données : un fichier reçu devient des lignes, et des lignes deviennent un fichier pour quelqu'un d'autre. Pour qui manipule de gros volumes, le faire dans le client plutôt que par un script permet de vérifier la correspondance avant l'exécution, et c'est cette partie qui fait gagner un après-midi.

Dessiner le schéma au lieu de le décrire

La modélisation visuelle est la fonction que l'on découvre tard et que l'on utilise ensuite sans arrêt. Tables, relations et contraintes se placent en les glissant, si bien qu'un schéma devient quelque chose que l'on regarde plutôt qu'un texte que l'on lit. Concevoir ainsi une nouvelle zone d'une base fait remonter les problèmes tôt : une clé étrangère manquante est évidente sur un schéma et invisible dans une liste d'instructions. Le même schéma sert en réunion, car pointer une case règle un désaccord plus vite que citer une définition.

Étendre quand la liste intégrée s'arrête

L'ouverture n'est pas ici qu'une question de licence. Parce que l'application est libre, sa couche de connexion peut être étendue, et un pilote pour une base non couverte d'origine peut être ajouté. Les équipes qui font tourner un moteur inhabituel, ou une version qui a changé de protocole, n'attendent pas qu'un fournisseur les remarque. Il en va de même des petites extensions : un outil qui s'insère dans un flux de travail précis se branche au lieu d'être demandé.

Pourquoi il finit installé partout

L'affirmation selon laquelle des millions de personnes l'utilisent se vérifie dans le sens qui compte : il est présent sur les machines des développeurs, des administrateurs de bases et des analystes, trois groupes aux métiers assez différents. Le développeur veut l'éditeur et la grille de résultats. L'administrateur veut les connexions, les droits et un moyen de voir ce que contiennent réellement les tables. L'analyste veut extraire un morceau de données. Un seul client au service des trois, voilà pourquoi il se répand dans une organisation sans que personne n'émette de consigne.

Gratuit, multiplateforme et honnête sur son périmètre

Il ne coûte rien et tourne sous Windows, macOS et Linux. C'est de l'édition communautaire qu'il s'agit ici ; des éditions plus lourdes existent pour les équipes qui en ont besoin, et le fait qu'une version gratuite reste réellement utilisable garde l'outil entre les mains des particuliers. Ce n'est pas un remplacement d'une plateforme décisionnelle complète et il ne prétend pas l'être. Ce qu'il fait est plus étroit et plus souvent nécessaire : se connecter à la base disponible, laisser écrire et vérifier une requête, faire entrer et sortir des données, et montrer la forme du schéma.

Par où commencer

Le premier pas raisonnable est de connecter une base que l'on connaît déjà et de n'utiliser que le navigateur pendant une journée, puis d'ouvrir l'éditeur et d'écrire une requête que l'on écrirait ailleurs. Le deuxième pas est d'essayer la vue de modélisation sur un schéma que l'on comprend, car c'est là que l'outil se distingue d'une simple console de requêtes. Le reste découle de ces deux habitudes.