Datentypen aus CSV richtig erkennen: INTEGER, DECIMAL, VARCHAR und Fallen

Warum der Datentyp überhaupt zählt

Eine CSV-Datei kennt nur eine einzige Sorte von Inhalt: Text. Jede Zelle ist eine Zeichenkette, egal ob darin 42, 3,14 oder Müller steht. Eine SQL-Datenbank dagegen verlangt für jede Spalte einen festen Datentyp. Sie müssen also entscheiden, ob eine Spalte als Ganzzahl, als Kommazahl, als Datum oder als Text gespeichert wird. Genau dieser Schritt, das Erkennen der SQL-Datentypen aus den CSV-Werten, entscheidet darüber, ob Ihre Daten später korrekt und durchsuchbar in der Datenbank landen.

Der richtige Typ hat handfeste Vorteile. Eine als INTEGER gespeicherte Spalte lässt sich sauber sortieren, addieren und mit Bereichen wie WHERE preis > 100 abfragen. Liegt dieselbe Zahl als Text vor, sortiert die Datenbank sie alphabetisch, sodass "100" plötzlich vor "99" steht und Rechnungen scheitern. Ein DATE erlaubt Zeitvergleiche und das Filtern nach Monaten, ein als Text gespeichertes Datum nicht. Der passende Typ spart außerdem Speicher und macht Indizes schneller.

Gleichzeitig ist ein zu enger Typ gefährlich. Wer eine Artikelnummer voreilig als Zahl deklariert, verliert führende Nullen und unter Umständen Inhalte. Die Kunst besteht also darin, den engsten Typ zu wählen, der noch zu allen Werten passt, und im Zweifel lieber einen Schritt allgemeiner zu bleiben. Wie das Tool aus den Spalten überhaupt eine Tabelle baut, lesen Sie im Ratgeber CREATE TABLE aus CSV generieren.

Wie man aus Werten den Typ erkennt

Die Logik dahinter ist einfacher, als sie klingt. Für jede Spalte schaut der Konverter sich alle nicht-leeren Werte an und prüft sie gegen eine feste Reihenfolge von Typen, vom strengsten zum allgemeinsten. Sobald ein einziger Wert nicht zum strengeren Typ passt, fällt die Spalte eine Stufe tiefer. Am Ende der Kette steht immer Text, denn Text passt zu allem.

1. BOOLEAN zuerst: Bestehen alle Werte aus Wahrheitswerten wie true, false, 0, 1, ja oder nein, wird die Spalte ein Wahrheitswert.
2. INTEGER: Sind alle Werte ganze Zahlen ohne Komma und ohne unzulässige führende Null (außer der reinen Null selbst), wird es eine Ganzzahl.
3. DECIMAL beziehungsweise REAL: Passen alle Werte zu einer Zahl mit Dezimaltrennzeichen, wird es eine Kommazahl. Das deutsche Komma wird dabei erkannt und intern auf einen Punkt normalisiert.
4. DATE: Sind alle Werte eindeutige Datumsangaben im ISO-Format JJJJ-MM-TT, wird die Spalte ein Datum. Diese Prüfung ist bewusst konservativ.
5. VARCHAR oder TEXT: Trifft nichts davon zu, bleibt die Spalte Text. Für kurze Felder wird die maximale Länge gemessen und auf eine sinnvolle VARCHAR-Größe aufgerundet.

Wichtig ist das Prinzip alle oder keiner: Hat eine sonst rein numerische Spalte einen einzigen Eintrag wie k.A., kann sie kein INTEGER sein und wird zu Text. Leere Zellen sind davon ausgenommen, sie kippen den Typ nicht, sondern werden später zu NULL. Eine Spalte mit mindestens einer leeren Zelle wird zudem als NULL-bar markiert und bekommt kein NOT NULL.

Die wichtigsten SQL-Datentypen im Überblick

Die folgende Tabelle zeigt, welcher CSV-Inhalt typischerweise zu welchem SQL-Datentyp führt und wofür sich der Typ eignet. Die genaue Schreibweise hängt vom Dialekt ab, dazu gleich mehr.

INTEGER, DECIMAL und der Unterschied zu VARCHAR

INTEGER ist die ganze Zahl ohne Nachkommastellen, ideal für Stückzahlen oder Jahreszahlen. DECIMAL (in manchen Dialekten REAL, DOUBLE oder FLOAT) speichert Kommazahlen und ist die richtige Wahl für Preise oder Messwerte. Der Begriff DECIMAL betont dabei eine feste Nachkommastellen-Genauigkeit, was gerade bei Geldbeträgen sauberer ist als das gerundete REAL. VARCHAR schließlich ist Text mit einer Obergrenze. Der entscheidende Unterschied: Eine Zahl in einer Zahlenspalte ist ein Rechenwert, dieselbe Ziffernfolge in VARCHAR ist nur eine Zeichenkette, die ihre exakte Schreibweise behält.

Dieselbe Spalte, je Dialekt anders geschrieben

Ein erkannter Typ heißt nicht in jeder Datenbank gleich. Eine als Kommazahl erkannte Spalte wird in MySQL zu DOUBLE, in PostgreSQL zu DOUBLE PRECISION, in SQLite zu REAL und in SQL Server zu FLOAT. Ein Wahrheitswert ist in PostgreSQL ein echtes BOOLEAN, in MySQL ein TINYINT(1), in SQL Server ein BIT und in SQLite schlicht ein INTEGER mit 0 und 1. Der Konverter übernimmt dieses Mapping automatisch, sobald Sie den Dialekt umschalten. Welcher Dialekt für Ihr Projekt der richtige ist, behandelt der Ratgeber SQL-Dialekte im Vergleich.

Die häufigsten Fallen, vor allem führende Nullen

Automatische Typ-Erkennung ist eine Heuristik, also eine begründete Vermutung anhand der Werte. Sie liegt meistens richtig, aber nicht immer. Die folgenden Fälle führen am häufigsten zu Problemen, und sie sind genau der Grund, warum unser Tool den erkannten Typ pro Spalte transparent anzeigt.

Führende Nullen: das klassische PLZ-Problem

Das ist die mit Abstand häufigste Falle bei führenden Nullen in der Umwandlung von CSV zu SQL. Eine deutsche Postleitzahl wie 01067 (Dresden) besteht nur aus Ziffern, also wird sie als INTEGER erkannt. Ein INTEGER speichert aber den Zahlenwert, nicht die Schreibweise. Aus 01067 wird die Zahl 1067, die führende Null ist unwiederbringlich weg. Dasselbe passiert mit Artikelnummern wie 00420, Kundennummern, Bankleitzahlen oder Telefonnummern mit Vorwahl-Null.

Die Lösung ist immer dieselbe: Solche Felder gehören als VARCHAR oder TEXT in die Datenbank, nicht als Zahl. Eine Postleitzahl rechnet niemand zusammen, sie ist ein Bezeichner, kein Rechenwert. Faustregel: Wenn mit einer Ziffernfolge nie gerechnet wird und die exakte Schreibweise zählt, ist es Text.

Telefonnummern und das Plus-Zeichen

Eine Nummer wie +49 40 1234567 enthält ein Pluszeichen, Leerzeichen und führende Strukturen, die in einer Zahl keinen Sinn ergeben. Selbst eine reine Ziffernnummer würde als INTEGER die Vorwahl-Null verlieren. Telefonnummern sind deshalb grundsätzlich Text.

Deutsche Kommazahlen und Tausenderpunkte

Das deutsche Dezimalkomma in 19,99 wird erkannt und intern zu 19.99 normalisiert, das funktioniert zuverlässig. Mehrdeutig wird es bei Tausenderpunkten: 1.234,56 könnte als Tausendertrennung oder fälschlich als zwei Zahlen gelesen werden. Solche Werte sollten Sie vor dem Umwandeln bereinigen, etwa indem Sie in Excel oder Ihrem Editor das Format vereinheitlichen, oder die Spalte bewusst als Text behandeln und in SQL später umrechnen.

Datumsformate: nur ISO ist sicher

Die Datums-Erkennung ist absichtlich konservativ. Nur eindeutige ISO-Daten wie 2026-06-17 werden zu DATE. Ein deutsches 17.06.2026 bleibt Text, denn die Reihenfolge Tag-Monat-Jahr ist nicht überall gleich, und eine Fehlinterpretation wäre schlimmer als ehrlicher Text. Brauchen Sie ein echtes Datumsfeld, formatieren Sie die Spalte vor dem Import auf ISO um.

Falsch erkannte Typen korrigieren

Damit Sie nicht raten müssen, zeigt der CSV-zu-SQL-Konverter für jede Spalte den erkannten Typ als kleine Badge an, etwa INTEGER oder TEXT. So sehen Sie auf einen Blick, wenn eine PLZ-Spalte fälschlich als Zahl gelandet ist. So gehen Sie dann vor:

1. Typen prüfen: Werfen Sie nach dem Einfügen oder Auswählen der CSV einen Blick auf die Typ-Badges jeder Spalte.
2. Verdächtige Spalten erkennen: Achten Sie besonders auf Felder mit Ziffern, die eigentlich Bezeichner sind, also PLZ, Kunden-, Artikel- und Telefonnummern.
3. Auf Text zwingen: Setzen Sie solche Spalten bewusst auf Text, damit führende Nullen und die exakte Schreibweise erhalten bleiben.
4. Ergebnis gegenlesen: Prüfen Sie den erzeugten CREATE-TABLE-Block. Sie können ihn auch nachträglich von Hand anpassen, etwa eine VARCHAR-Länge erhöhen.

Diese kurze Kontrolle dauert Sekunden und erspart Ihnen den Ärger, eine ganze Tabelle erneut importieren zu müssen, weil eine Spalte stillschweigend Daten verloren hat. Wenn das Schema steht, geht es weiter mit den Daten selbst: Wie die einzelnen Zeilen als Anweisungen entstehen, lesen Sie unter INSERT-Statements aus CSV erzeugen. Und falls Ihre Datei mit Semikolon statt Komma getrennt ist, hilft der Ratgeber CSV mit Semikolon in SQL.

Eine ehrliche Einordnung zum Schluss: Das Tool erzeugt eine flache Einzeltabelle mit erkannten Typen sowie NULL- und NOT-NULL-Angaben. Es setzt keine Fremdschlüssel, keine UNIQUE- oder CHECK-Regeln und erkennt keine Beziehungen zwischen mehreren CSV-Dateien. Für den Weg von einer Tabellendatei zu einer fertigen Datenbank ist das genau richtig, ein vollständiges Datenmodell mit verknüpften Tabellen bleibt aber Handarbeit.

Häufige Fragen