Das Problem ist selten eine einzige Datenbank

Wer beruflich mit Daten arbeitet, sammelt mit der Zeit eine kleine Sammlung davon an. Ein Produktivsystem auf einer Engine, eine lokale Kopie auf einer anderen, ein Kundenprojekt auf einer dritten, dazu eine Tabelle, die jemand geschickt hat und die erst irgendwo hinein muss, bevor man sie befragen kann. Die übliche Antwort ist ein eigener Client je Engine, jeder mit eigenen Tastenkürzeln und eigener Vorstellung davon, wohin Ergebnisse gehören. DBeaver Community geht den umgekehrten Weg: eine Anwendung, die mit allen spricht, sodass das Fingerwissen von einer Datenbank auf die nächste übergeht.

Ein Fenster, das wie eine Datenbank aufgebaut ist

Das Hauptfenster folgt der Logik der Arbeit. Auf einer Seite steht ein Browser, der Verbindungen, Schemata und Tabellen als Baum zeigt, sodass die Form der Daten ohne Abfrage sichtbar ist. In der Mitte liegt der SQL-Editor. Darunter oder daneben kommt das Ergebnisfenster. Der Wechsel zwischen diesen drei Teilen ist beim Arbeiten ständig, und sie beieinander zu halten heißt, dass die Antwort neben der Frage erscheint statt in einem weiteren Fenster, das man erst anordnen muss. Kontextmenüs und eine Werkzeugleiste tragen die Abläufe, die sich am häufigsten wiederholen: eine Tabelle öffnen, Zeilen filtern, einen Wert ändern, Daten entfernen, die dort nicht hingehören.

Relational und nicht relational an derselben Stelle

Die Liste der unterstützten Engines ist der Grund, warum viele es installieren. Relationale Systeme wie MySQL, PostgreSQL und Oracle sind abgedeckt, ebenso nicht relationale Speicher wie MongoDB und Cassandra. Diese Mischung zählt in der Praxis, weil moderne Systeme selten in einer Kategorie bleiben. Eine Migration liest aus der alten Engine und schreibt in die neue; eine Designbesprechung hält ein relationales Schema neben einen Speicher, der den flexiblen Teil aufnimmt. Beides von einem Client aus erreichen zu können macht aus solchen Aufgaben eine Sitzung voller Kontextwechsel und zwei Registerkarten.

Ein Editor für Leute, die den Tag über Abfragen schreiben

Syntaxhervorhebung ist das Minimum und vorhanden. Nützlicher ist eine Vervollständigung, die das Schema kennt, sodass Tabellen- und Spaltennamen auftauchen, ohne auswendig gelernt zu sein. Formatierung räumt eine Abfrage auf, die beim Fehlersuchen seitwärts gewachsen ist, und macht sie am nächsten Morgen wieder lesbar. Jede Engine hat ihren Dialekt, und der Editor folgt dem gerade benutzten, statt so zu tun, als seien sie austauschbar. Für alle, deren Tag aus einer Folge von Abfragen besteht, ist das kein Luxus, sondern der Unterschied zwischen einmal geschrieben und neu geschrieben, weil ein Name falsch war.

Daten hinein und wieder hinaus

An Import und Export entscheidet sich, ob ein Datenbankwerkzeug seinen Platz verdient oder zur Last wird. DBeaver liest CSV- und Tabellenformate und schreibt sie auch zurück, mit Spaltenzuordnung währenddessen. Das deckt die beiden Richtungen ab, in die Daten üblicherweise wandern: eine fremde Datei wird zu Zeilen, und Zeilen werden zu einer Datei für jemand anderen. Wer große Mengen bewegt, kann die Zuordnung vor dem Lauf prüfen, weil sie im Client statt in einem Skript passiert, und genau dieser Teil spart einen Nachmittag.

Das Schema zeichnen statt es beschreiben

Visuelle Modellierung ist die Funktion, die man spät entdeckt und dann ständig nutzt. Tabellen, Beziehungen und Bedingungen lassen sich durch Ziehen platzieren, sodass ein Schema etwas ist, das man ansieht, statt etwas, das man als Text liest. Wer so einen neuen Bereich einer Datenbank entwirft, sieht Probleme früh: ein fehlender Fremdschlüssel ist in einem Diagramm offensichtlich und in einer Liste von Anweisungen unsichtbar. Dasselbe Diagramm hilft im Gespräch, weil ein Finger auf einem Kasten einen Streit schneller beendet als das Zitieren einer Definition.

Erweitern, wenn die eingebaute Liste endet

Offenheit ist hier nicht nur eine Lizenzfrage. Weil die Anwendung quelloffen ist, lässt sich ihre Verbindungsschicht erweitern, und ein Treiber für eine Datenbank, die nicht ab Werk abgedeckt ist, kommt dazu. Teams mit einer ungewöhnlichen Engine oder einer Version, die ihr Protokoll geändert hat, warten nicht darauf, dass ein Anbieter sie bemerkt. Für kleinere Erweiterungen gilt dasselbe: ein Werkzeug, das in einen bestimmten Ablauf passt, wird eingehängt statt beantragt.

Warum es am Ende überall installiert ist

Die Aussage, Millionen Menschen nutzten es, lässt sich in dem Sinne prüfen, auf den es ankommt: Es steht auf den Rechnern von Entwicklern, Datenbankadministratoren und Analysten, also drei Gruppen mit recht verschiedenen Aufgaben. Entwickler wollen den Editor und das Ergebnisraster. Administratoren wollen Verbindungen, Rechte und einen Weg zu sehen, was tatsächlich in den Tabellen steht. Analysten wollen einen Ausschnitt der Daten herausziehen. Ein Client für alle drei ist der Grund, warum es sich in einer Organisation verbreitet, ohne dass jemand eine Anweisung erteilt.

Kostenlos, plattformübergreifend und ehrlich im Umfang

Es kostet nichts und läuft auf Windows, macOS und Linux. Beschrieben ist hier die Community-Ausgabe; für Teams mit weitergehenden Anforderungen gibt es größere Ausgaben, und dass eine kostenlose Fassung wirklich brauchbar bleibt, hält das Werkzeug in den Händen Einzelner. Es ersetzt keine vollständige Business-Intelligence-Landschaft und versucht das auch nicht. Was es tut, ist enger und wird häufiger gebraucht: sich mit der vorhandenen Datenbank verbinden, eine Abfrage schreiben und prüfen lassen, Daten hinein und hinaus bewegen und die Form des Schemas zeigen.

Wo man anfängt

Der vernünftige erste Schritt ist, eine bereits vertraute Datenbank zu verbinden und einen Tag lang nur den Browser zu benutzen, dann den Editor zu öffnen und eine Abfrage zu schreiben, die man sonst woanders schreibt. Der zweite Schritt ist die Modellierungsansicht an einem Schema, das man versteht, denn dort fühlt sich das Werkzeug anders an als eine reine Abfragekonsole. Alles Weitere folgt aus diesen zwei Gewohnheiten.