XLSX in SQL umwandeln

Eine Mitgliederliste im Excel-Format, die in die Datenbank eines Vereinsverwaltungsprogramms soll, ein Ersatzteilbestand, den ein Handwerksbetrieb ins eigene System übernehmen will, ein Adressbestand, den eine Kommune in ein bestehendes Fachverfahren einspielt — in allen drei Fällen existiert die Tabelle bereits, mit ihren Spalten und Regeln, und gebraucht werden nur die Zeilen darin.

Genau das liefert diese Seite: reine INSERT-Anweisungen, ohne eine Vermutung darüber, wie die Tabelle aufgebaut sein soll. Eine Tabellenkalkulation kennt keine Datentypen, keine Schlüssel, keine Längenbeschränkung — jede daraus abgeleitete CREATE-TABLE-Anweisung wäre eine Annahme, die sich als Tatsache ausgibt, und ein falscher Spaltentyp kostet später weit mehr als eine falsche Zeile: eine VARCHAR(50), die zwei Jahre später Adressen abschneidet, tut das leise und wird erst bei einer besonders langen Straße bemerkt.

Der Name der Arbeitsmappe ohne Endung wird zum Tabellennamen in jeder Anweisung. Er wird dabei bereinigt: Alles, was kein Buchstabe, keine Ziffer und kein Unterstrich ist, wird zu einem Unterstrich, und ein mit einer Ziffer beginnender Name bekommt einen vorangestellt — aus „2025 Mitglieder.xlsx" wird also in die Tabelle _2025_Mitglieder eingefügt.

Die praktische Folge: die Datei vor dem Umwandeln exakt so benennen wie die Zieltabelle, dann läuft das Ergebnis unverändert. Der umgekehrte Weg bedeutet ein Suchen-und-Ersetzen über tausende Zeilen, bei dem sich leicht ein falscher String einschleicht. Dieselbe Bereinigung gilt für die Spaltennamen aus der Kopfzeile — eine Überschrift wie „Beitrag (EUR)" wird zu Beitrag__EUR_ und passt dann nicht mehr zur echten Spalte. Die Kopfzeile vorher anzugleichen erspart jede Nacharbeit am Ergebnis.

Zahlen stehen unquotiert da. Text steht in einfachen Anführungszeichen, ein Apostroph darin wird verdoppelt — das ist die ANSI-Form, die jede gängige Datenbank versteht. Eine Backslash-Maskierung wird bewusst nicht verwendet, weil sie eine MySQL-Erweiterung ist, deren Verhalten von einer Servereinstellung abhängt statt von der Anweisung selbst.

Eine leere Zelle wird zum Schlüsselwort NULL statt zu einer leeren Zeichenkette, was in fast jedem Fall die richtige Lesart eines leeren Feldes in einer Tabellenkalkulation ist — relevant, wenn eine Spalte NOT NULL verlangt. Ein Preis, der als 19,99 mit zwei Nachkommastellen angezeigt wird, kommt genauso als 19.99 heraus; die Tabellenkalkulation rechnet mit der gespeicherten Genauigkeit, nicht mit der Anzeige.

Eine Boolean-Zelle wird als das Schlüsselwort TRUE oder FALSE geschrieben. Postgres akzeptiert das direkt, MySQL behandelt es als Alias für 1 und 0, SQLite ebenso seit Jahren. Ein Fachverfahren, das auf Microsoft SQL Server läuft — in deutschen Kommunalverwaltungen keine Seltenheit —, versteht es nicht: Der bit-Typ dort verlangt 1 und 0, und die Anweisung scheitert am Parsen.

Wer die Zielumgebung kennt, ersetzt die Literale vor dem Ausführen — zwei Minuten Arbeit gegen zwanzig genervte, wenn der Fehler erst bei Anweisung vierhundert auffällt. Ein Blick auf die erste Zeile der Datei zeigt Tabellennamen, Spaltenliste und je ein Beispiel jedes Werttyps auf einen Blick, und ist die schnellste Prüfung, die diese Datei je bekommt.

Eine Tabellenkalkulation speichert ein Datum intern als Zahl mit einem Anzeigeformat darüber, nicht als Text. Ob eine solche Zelle in der erzeugten INSERT-Anweisung als diese rohe Zahl oder in einer anderen Form ankommt, hängt vom Einzelfall ab — verlassen sollte man sich darauf nicht, sondern die erste erzeugte Zeile für genau diese Spalte kontrollieren, bevor die ganze Datei ausgeführt wird.

In einer numerischen Spalte landet ein unerwarteter Wert dieser Art still und falsch, in einer Datumsspalte wird er abgelehnt — wenigstens laut. Beides ist unerwünscht. Die sauberere Lösung ist eine Staging-Spalte in der Datenbank, in der die Umrechnung eine einzelne, dokumentierte Anweisung ist, statt etwas, das beim letzten Mal jemand von Hand gemacht hat.

Ein als Text gespeicherter Code kommt als gequoteter String heraus, sodass eine Mitgliedsnummer 007 als '007' ankommt und in eine VARCHAR-Spalte intakt eingefügt wird. Das ist der Gegensatz zu dem, was bei einer sorglosen CSV-Zwischenstation passiert, wo solche Spalten zu Zahlen werden und die führenden Nullen schon vor jeder Umwandlung verloren sind.

Der brauchbare Test, ob eine Spalte ein Bezeichner ist: Würde die Addition zweier Werte irgendetwas bedeuten? Postleitzahlen, Mitgliedsnummern, Telefonnummern und Aktenzeichen scheitern alle daran und gehören ebenso in der Zieltabelle in eine Textspalte. War die Spalte in der Arbeitsmappe selbst schon eine Zahl, ist die führende Null bereits weg, bevor irgendeine Umwandlung beginnt.

Manchmal existiert die Zieltabelle noch nicht, und die Versuchung ist groß, das CREATE TABLE aus den Excel-Spalten raten zu lassen. Das ist genau der Fall, in dem diese Seite bewusst nichts anbietet: Die Entscheidung, ob eine Spalte INT oder BIGINT wird, ob ein Text VARCHAR(50) oder VARCHAR(255) verdient, und welche Spalte den Primärschlüssel bildet, ist eine, die jemand treffen sollte, der die Daten kennt — nicht eine, die aus der zufälligen Breite einer Excel-Spalte abgeleitet wird.

Zwei Minuten für eine handgeschriebene CREATE-TABLE-Zeile am Anfang der Datei kosten wenig und halten fest, wer welche Entscheidung wann getroffen hat. Die von dieser Seite erzeugten INSERT-Anweisungen laufen unverändert dagegen, sobald die Tabelle einmal angelegt ist.

Jede Anweisung nennt ihre Spalten ausdrücklich, statt sich auf die Reihenfolge in der Tabelle zu verlassen — das macht die Datei robust gegen eine seither hinzugekommene Spalte. Die Spaltenmenge ist die Vereinigung aller Felder, die irgendwo im Tabellenblatt vorkommen, sodass ein Feld, das erst weiter unten auftaucht, trotzdem in der Liste steht, mit NULL für die Zeilen, denen es fehlt.

Diese Ausführlichkeit hat einen Preis: Die Spaltenliste steht in jeder Zeile erneut, die Datei ist deshalb größer als die Daten darin. Fünfzigtausend Zeilen mit sechs Spalten ergaben etwa 5,7 MB SQL gegenüber rund 4,3 MB für die Arbeitsmappe, aus der sie stammen — das einzige der Zielformate hier, das größer ist als die Excel-Datei selbst.

Die Anweisungen stehen einzeln, ohne Transaktion darum und ohne Bündelung in eine mehrzeilige VALUES-Klausel. Unverändert gegen Postgres oder MySQL ausgeführt, sind das fünfzigtausend Hin- und Rückwege und fünfzigtausend einzelne Commits — spürbar langsam, und bei einem Abbruch in der Mitte bleibt eine halb gefüllte Tabelle zurück.

Die Datei in BEGIN und COMMIT einzupacken behebt beides für zwei zusätzliche Zeilen. Für wirklich große Bestände ist der Massenimport der bessere Weg — COPY bei Postgres, LOAD DATA bei MySQL, .import bei SQLite —, der eine getrennte Datei direkt liest und um ein Vielfaches schneller ist. Dafür ist eine Umwandlung nach CSV oder TSV die passendere Wahl.

Verarbeitet wird das erste Tabellenblatt der Arbeitsmappe, weil ein Satz INSERT-Anweisungen genau eine Tabelle adressiert. Steht das gewünschte Blatt nicht an erster Stelle, hilft es, es innerhalb der Mappe nach vorn zu verschieben und neu umzuwandeln; sollen mehrere Tabellenblätter in mehrere Tabellen, wird pro Blatt einmal umgewandelt, mit der Datei jeweils passend zum Zielnamen benannt.

Alles läuft dabei im Browser: Die Arbeitsmappe wird gelesen und die Anweisungen werden auf der Seite geschrieben, ohne Upload und ohne Anfrage, die die Datei mitführt. Das zählt hier mehr als bei den meisten anderen Umwandlungen, weil eine Tabelle auf dem Weg in eine Datenbank sehr häufig Kunden- oder Finanzdaten enthält, die auf keiner fremden Website landen sollten.

Eine echte Mitgliederliste eines Sportvereins hat üblicherweise eine Mitgliedsnummer als Text, einen Beitrittstag als Datum, einen Jahresbeitrag als Zahl mit zwei Nachkommastellen, ein Feld für den SEPA-Lastschrift-Status als Boolean und mehrere Zeilen, in denen das Austrittsdatum leer ist, weil das Mitglied noch aktiv ist. Genau diese fünf Spaltentypen sind die fünf Fälle, die auf dieser Seite behandelt werden, und keiner von ihnen kommt unverändert aus der Tabellenkalkulation heraus.

Wer eine solche Liste zum ersten Mal umwandelt, prüft am besten genau diese fünf Spalten in der ersten erzeugten Zeile: die Mitgliedsnummer in Anführungszeichen, das Beitrittsdatum in der Form, in der es tatsächlich ankommt, den Beitrag mit der richtigen Anzahl Nachkommastellen, TRUE oder FALSE für die Lastschrift, und NULL für das leere Austrittsdatum. Stimmen diese fünf, stimmt praktisch die ganze Datei.

Ist die Zieltabelle leer und der Bestand groß, ist der Umweg über SQL der langsame. Jede Datenbank bringt einen Massenlader mit, der eine getrennte Datei direkt einliest, Typen einmalig anwendet und blockweise schreibt — bei mehr als ein paar tausend Zeilen deutlich schneller als ein Skript aus INSERT-Anweisungen.

INSERT-Anweisungen verdienen ihren Platz, wenn die Menge klein ist, wenn sie vor der Ausführung geprüft oder versioniert werden soll, wenn dieselbe Änderung in mehreren Umgebungen wiederholt wird, oder wenn nur ein Abfragefenster zur Verfügung steht und kein Dateisystemzugriff. Genau das ist der übliche Fall in einem Vereins- oder Kommunalbetrieb, und für den ist diese Seite gedacht.