Was ist eine SQL-Datei?

SQL ist ein reines Textformat, das sich in jedem Editor öffnen lässt. Eingesetzt wird es für den Austausch zwischen Programmen und die Archivierung.

Die Endung lautet .sql, der volle Name SQL Insert Statements. Beides sagt weniger aus als das, was die Datei halten kann — und davon handelt der Rest dieser Seite.

Es geht auf 1986 zurück. Die Spezifikation ist ISO/IEC 9075.

Einem Format, das so lange lesbar geblieben ist, kann man etwas anvertrauen, das man in zehn Jahren wiederhaben will.

Sie ist vollständig veröffentlicht, das Format lässt sich also aus dem Dokument umsetzen statt durch Nachsehen. Deshalb taucht es in so vielen Programmen auf, und deshalb gehen Dateien von vor zwanzig Jahren heute noch auf. Veröffentlicht heißt allerdings nicht lizenzfrei: Wo ein Format einen Codec einpackt, ist die Patentfrage eine eigene, die der Standard nicht mitbeantwortet.

SQL hat eine Kommentarsyntax — das ist der Unterschied zwischen einer Datei, die ein Mensch pflegt, und einer, die ein Programm schreibt. Beim Umwandeln in ein Format ohne Kommentare sind sie das Erste, was verschwindet, und gewarnt wird nicht.

PostgreSQL, MySQL und DBeaver lesen es, und die meisten Programme derselben Art ebenfalls.

Wenn eine Datei nicht aufgeht, liegt es selten am Format — häufiger daran, dass das Programm älter ist als das Format. Die Umwandlung in etwas Älteres ist der verlässliche Weg daran vorbei, und dafür gibt es den Rest dieser Website.

Kein Browser liest es.

Das ist der häufigste Grund, es umzuwandeln: nicht dass das Format schlecht wäre, sondern dass die Stelle, an der die Datei erscheinen soll, es nicht lesen kann.

SQL ist zum Öffnen und Ändern gedacht. Behalte die Datei in diesem Format, solange die Arbeit läuft, und exportiere daraus, wann immer eine fertige Fassung gebraucht wird.

SQL ist eine seit 1986 standardisierte Abfragesprache. Eine .sql-Datei ist eine Textdatei mit Anweisungen darin, und das ist bereits das ganze Format — kein Kopf, keine Struktur, kein Weg, aus der Endung zu erkennen, was eine bestimmte Datei tut. Sie kann Tabellen anlegen, eine Million Zeilen einfügen, ein Schema ändern, oder einfach drei Abfragen enthalten, die jemand aufheben wollte.

In der Praxis fallen die ausgetauschten Dateien in zwei Gruppen. Ein Dump ist eine Datenbank oder Tabelle, als Anweisungen geschrieben, die sie anderswo nachbilden. Eine Migration ist ein Skript, das ein Schema kontrolliert verändert. Beides ist Text, beides öffnet sich in jedem Editor, und die beiden zu verwechseln ist der Grund, warum ein Skript, das eine Spalte hinzufügen sollte, eine Tabelle löscht.

Meist drei Dinge nacheinander. Eine Anweisung, die die Tabelle löscht, falls sie existiert — weshalb ein Dump gegen eine lebende Datenbank auszuführen keine rückgängig zu machende Handlung ist. Eine CREATE-TABLE-Anweisung mit den Spalten und ihren Typen. Dann die Zeilen als INSERT-Anweisungen — manchmal eine pro Zeile, manchmal mehrere Hundert zu einer Anweisung gebündelt, was das Laden deutlich schneller, aber viel schwerer lesbar macht.

Drumherum fügt ein echter Dump Verwaltungsarbeit hinzu: Zeichensatz-Angaben, Einstellungen, die den Indexaufbau während des Ladens aussetzen, und eine Transaktionshülle, damit ein Abbruch mittendrin nichts Halbes hinterlässt. Diese Verwaltungsarbeit ist datenbankspezifisch, und sie ist der Hauptgrund, warum sich ein Dump aus einer Datenbank nicht in eine andere laden lässt.

Der Standard legt einen Kern fest, und jede Datenbank erweitert ihn. Bezeichner-Anführung unterscheidet sich — Backticks bei MySQL, doppelte Anführungszeichen bei PostgreSQL, eckige Klammern bei SQL Server. Automatisch hochzählende Schlüssel werden auf drei verschiedene Weisen geschrieben. Datumsfunktionen, Textfunktionen, der Umgang mit Wahrheitswerten und die Typnamen selbst weichen ebenfalls voneinander ab.

Ein MySQL-Dump lädt deshalb nicht in PostgreSQL, und die Fehlermeldung ist meist eine Syntaxbeschwerde in Zeile vier statt einer Erklärung. Zwischen Dialekten zu übersetzen ist echte, meist mechanische Arbeit — geht es um Daten und nicht um ein Schema, ist der Umweg über CSV häufig schneller und zuverlässiger, als das SQL zu übersetzen.

Auf der Kommandozeile hat jede Datenbank ihr eigenes Werkzeug, und der Aufruf ist kurz: psql für PostgreSQL, der mysql-Client für MySQL und MariaDB, sqlite3 für SQLite — alle nehmen die Datei als Eingabe. Das ist bei großen Dumps mit weitem Abstand der schnellste Weg; ein grafisches Werkzeug, das die Datei erst komplett in den Arbeitsspeicher liest, kommt bei allem jenseits ein paar hundert Megabyte an seine Grenzen.

Zwei Dinge vorher prüfen. Den Anfang der Datei lesen, um zu sehen, ob etwas gelöscht wird. Und die Zieldatenbank vorher anlegen, falls der Dump sie nicht selbst erzeugt — ein für einen bestimmten Datenbanknamen geschriebener Dump erfindet keinen anderen.

Meist einer von vier Gründen. Eine Grenze für Paket- oder Anweisungsgröße, ausgelöst von einem gebündelten INSERT mit mehreren tausend Zeilen — die Grenze des Servers, nicht der Datei. Ein Timeout in einem grafischen Client, der auf der Kommandozeile keine Entsprechung hat. Eine falsche Zeichensatz-Angabe, die eher als verstümmelter Text auffällt denn als Fehlermeldung, und die es sich lohnt, früh zu erkennen. Oder eine Fremdschlüsselbedingung, die Zeilen ablehnt, die ankommen, bevor die referenzierte Tabelle existiert.

Der letzte Punkt ist der häufigste und der am wenigsten offensichtliche. Dumps handhaben ihn meist, indem sie die Prüfung während des Ladens abschalten, und ein von Hand bearbeiteter Auszug — ein paar Tabellen aus einer größeren Datei herausgelöst — verliert diesen Schutz. Das Laden in Abhängigkeitsreihenfolge oder das Wiederherstellen der Hülle löst das.

Ein Dump dient dazu, eine Datenbank nachzubilden. Geht es um die Daten selbst — analysieren, in eine Tabellenkalkulation laden, an jemanden weitergeben, der keine Datenbank betreibt — ist CSV der bessere Behälter, und Parquet ist es bei allem, dessen Größe den Unterschied spürbar macht, noch mehr.

Umgekehrt lohnt es sich ebenso zu wissen: Eine Tabellenkalkulation in INSERT-Anweisungen zu verwandeln ist der Standardweg, eine Tabelle in eine Datenbank zu bekommen, wenn keine direkte Verbindung besteht — eine häufige Situation bei gehostetem Webspace ohne offenen Port, aber mit einer Abfragekonsole, die eine eingefügte Datei anstandslos ausführt.

Es ist Text, jeder Editor öffnet ihn. Ein Editor, der SQL-Syntax versteht, lohnt sich für alles, das ausgeführt werden soll, weil er die Anweisungen einfärbt und ein fehlendes Anführungszeichen sichtbar macht, bevor die Datenbank darauf stößt.

Ein Dump kann sehr groß sein, und die vernünftige Art, einen mehrere Gigabyte großen anzusehen, ist ein Blick auf die ersten und letzten paar Dutzend Zeilen statt das Öffnen der ganzen Datei. Die ersten verraten Dialekt, Zeichensatz und ob etwas gelöscht wird; die letzten verraten, ob der Dump zu Ende geschrieben wurde — die nützlichste einzelne Information über eine Datei, die einem geschickt wurde.