ToolActToolAct

CSV-zu-SQL-Konverter

CSV-Datei hochladen oder Daten einfügen, um sie in SQL-INSERT-Anweisungen zu konvertieren

CSV-Datei hier ablegen oder klicken, um eine Datei auszuwählen

Was ist CSV zu SQL?

CSV zu SQL ist ein Online-Datenformatkonvertierungstool, das Daten im CSV-Format (Comma-Separated Values) in SQL-INSERT-Anweisungen konvertiert, um den Import in Datenbanken zu erleichtern.

CSV ist ein verbreitetes tabellarisches Datenformat, das häufig für Tabellenkalkulationen und Datenexporte verwendet wird. SQL ist die standardmäßige Abfragesprache für relationale Datenbanken, und INSERT-Anweisungen werden verwendet, um Daten in Datenbanktabellen einzufügen.

Mit diesem Tool können Sie CSV-Daten schnell in ausführbare SQL-Anweisungen konvertieren. Es unterstützt benutzerdefinierte Tabellennamen, Feldnamen und Anführungszeichen-Stile für einfache Datenmigration und Importvorgänge.

CSV zu SQL erzeugt aus Tabellendaten INSERT- oder ähnliche SQL-Anweisungen, doch die sichere Nutzung hängt von Datentypen, Escaping, null-Werten und Ziel-Dialekt ab. Spaltennamen sollten geprüft und reservierte Wörter vermieden oder korrekt quoted werden. Für produktive Datenimporte sind Transaktionen, Backups, Zeichencodierung und ein Testlauf auf einer Kopie wichtiger als die reine Generierung des SQL-Texts.

Anleitung

Anleitung

  1. CSV-Daten in das Eingabefeld einfügen oder eine CSV-Datei hochladen
  2. Tabellennamen festlegen (Standard ist table_name)
  3. Trennzeichen wählen (Standard: Komma)
  4. Wählen Sie, ob die erste Zeile als Feldnamen verwendet werden soll
  5. SQL INSERT-Anweisungen werden auf der rechten Seite generiert

Import-Sicherheit

  • Überprüfen Sie die generierten INSERT-Anweisungen auf Tabellennamen, Spaltenreihenfolge, Escaping, NULL-Werte und numerische Formate vor der Ausführung.
  • Führen Sie zunächst einen kleinen Batch aus und kapseln Sie echte Importe in einer Transaktion, sofern Ihre Datenbank dies unterstützt.

Anwendungsfälle

INSERT-Anweisungen aus einem kleinen CSV-Export generierenEine CSV-, TSV- oder Textdatei hochladen, Trennzeichen wählen, den Tabellennamen festlegen und SQL-INSERT-Anweisungen mit Kopfzeilennamen oder generierten col1, col2, col3-Spalten erzeugen. Parsing und Anweisungsgenerierung laufen im Browser, sodass die importierten Zeilen das Gerät erst verlassen, wenn sie in psql, mysql oder das Migrationstool eingefügt werden.
Identifier-Quoting an den Datenbankstil anpassenZwischen Akutzeichen für MySQL, doppelten Anführungszeichen für PostgreSQL/Standard-SQL und einfachen Anführungszeichen für String-Literale wechseln und optional eine einfache CREATE TABLE-Anweisung mit VARCHAR(255)-Spalten einbeziehen. Als kontrollierten Zwischenschritt nutzen und dann das SQL gegen die Zieldatenbankversion verifizieren.
Seed-Daten vorbereiten und SQL-Grenzen im Blick behaltenDas Tool escaped einfache Anführungszeichen und verdoppelt sie in Werten, unterstützt vier Trennzeichen und eignet sich gut für Demos, lokale Fixtures und Admin-Reparaturentwürfe, leitet aber keine Datentypen, Constraints, Indizes, Transaktionen oder datenbankspezifische Bulk-Load-Syntax wie COPY, LOAD DATA oder mehrzeilige VALUES-Batches ab.
IF NOT EXISTS-Guards beim Seeding gemeinsamer Datenbanken hinzufügenDen generierten INSERT-Batch in eine BEGIN/COMMIT-Transaktion einpacken oder mit einem manuellen DELETE/INSERT-Muster kombinieren, damit ein erneutes Seeding keine Zeilen in Entwicklungs- und Staging-Schemata dupliziert. Da alles lokal geparst wird, kann der Seed ohne erneutes Hochladen iteriert werden.
VARCHAR(255) anpassen, wenn reale Spalten TEXT oder DECIMAL benötigenDer CREATE TABLE-Entwurf verwendet VARCHAR(255) für jede Spalte, daher lange Beschreibungen auf TEXT, Geldbeträge auf DECIMAL(p,s) und Zeitstempel auf TIMESTAMP in der Migration anpassen, bevor die Inserts in Produktion laufen. Die generierten Spaltentypen gegen das reale Schema prüfen statt den Entwurf wörtlich zu übernehmen.

Technisches Prinzip

Die CSV-Eingabe wird mit einer RFC-4180-konformen Zustandsmaschine geparst (Behandlung von quoteten Feldern, escaped verdoppelten Anführungszeichen und CRLF/LF-Zeilenumbrüchen) und dann als ANSI-SQL-INSERT-Anweisungen ausgegeben. Die beiden Grammatiken überlappen sich nicht: CSV verwendet Verdopplung von doppelten Anführungszeichen zum Escaping ("O""Brien"), während SQL innerhalb von String-Literalen einfache Anführungszeichen verdoppelt ('O''Brien') gemäß ISO/IEC 9075. Der Konverter schreibt jedes interne Apostroph in ein verdoppeltes Paar um, bevor der Wert in einfache Anführungszeichen eingeschlossen wird - dies ist der einzige Escaping-Mechanismus, der für MySQL, PostgreSQL, SQLite, SQL Server und Oracle garantiert funktioniert. Das Identifier-Quoting ist dialektabhängig: MySQL verwendet Backticks `users`, PostgreSQL und SQL Server verwenden doppelte Anführungszeichen "users" (case-sensitive wenn gequotet), und SQLite akzeptiert beides - wählen Sie den Stil, der zur Zieldatenbank passt, um "unknown column"-Fehler durch Case-Folding zu vermeiden. Die Tyinferenz ist bewusst minimal, da CSV keine Typmetadaten hat. Der optionale CREATE TABLE-Entwurf gibt VARCHAR(255) für jede Spalte aus - sicher, aber suboptimal - und überlässt es dem Benutzer, INT, BIGINT, DECIMAL(p,s), DATE, TIMESTAMP oder TEXT zu substituieren, bevor er gegen die Produktionsumgebung ausführt. Leere Zellen werden als NULL ausgegeben (der SQL-Dreiwertelogik-Absenzmarker) und nicht als leerer String '', da die meisten Tabellenkalkulationsexporte ein leeres Feld für fehlende Daten verwenden; wenn die Leer-String-Unterscheidung wichtig ist, wechseln Sie zu einem typisierten Loader. Reservierte Wörter wie user, order und group werden NICHT automatisch gequotet, eine Spalte namens order wird daher auf MySQL fehlschlagen, es sei denn, der Benutzer umschließt sie manuell mit Backticks. Für große Imports sind Einzelzeilen-INSERT-Anweisungen korrekt aber langsam: MySQLs Standard-max_allowed_packet beträgt 64 MB und ein mehrzeiliges INSERT INTO t VALUES (...), (...), (...) in Batches von ca. 1000 Zeilen pro Anweisung ist typischerweise 5-10x schneller als eine Anweisung pro Zeile, wegen Netzwerk-Roundtrip und Parsing-Overhead. Das Einpacken des Batches in BEGIN; ... COMMIT; lässt die Datenbank die Inserts zwischenspeichern und atomar committen, was unerlässlich ist, wenn ein partieller Insert eine Fremdschlüsselbeziehung inkonsistent hinterlassen würde. Beachten Sie, dass dieses Tool keine Fremdschlüssel, Indizes, Primary-Key-Constraints oder AUTO_INCREMENT ableitet - es konvertiert nur Zeilendaten, daher muss das empfangende Schema bereits existieren oder der CREATE TABLE-Entwurf muss vor der Ausführung bearbeitet werden. Für Bulk-Loads von Millionen Zeilen bevorzugen Sie datenbanknative Syntax: PostgreSQL COPY FROM, MySQL LOAD DATA INFILE oder SQL Server bcp.

  • SQL-String-Literal-Escaping gemäß ISO/IEC 9075: Einfache Anführungszeichen werden verdoppelt ('O''Brien'), nicht mit Backslash escaped.
  • Identifier-Quoting unterscheidet sich: ` für MySQL, " für PostgreSQL/SQL Server, beides akzeptiert in SQLite.
  • Leere CSV-Zelle -> SQL NULL (Dreiwertelogik), nicht '' - die Leer-String-Unterscheidung geht verloren.
  • Reservierte Wörter (order, user, group) werden nicht automatisch gequotet; manuelles Escaping erforderlich.
  • Mehrzeilige INSERT-Batches von ca. 1000 Zeilen erreichen ca. 5-10x Durchsatz gegenüber Einzelzeilen-Anweisungen (MySQL max_allowed_packet 64 MB Standard).
  • Mit BEGIN; ... COMMIT; einpacken für atomare Seed-Inserts; partielle Fehler werden sauber zurückgerollt.
  • Bulk-Loads über 1 Mio. Zeilen: PostgreSQL COPY, MySQL LOAD DATA INFILE, SQL Server bcp gegenüber generierten INSERTs bevorzugen.

Beispiele

Einfache CSV -> INSERT-Anweisungen (MySQL Backtick)

CSV:
id,name,email
1,Alice,alice@example.com
2,Bob,bob@example.com

SQL:
INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');
INSERT INTO `users` (`id`, `name`, `email`) VALUES (2, 'Bob',   'bob@example.com');

Mit CREATE TABLE (PostgreSQL doppelte Anführungszeichen)

CSV:
product_id,price,in_stock
101,29.99,true
102,15.50,false

SQL:
CREATE TABLE "products" (
  "product_id" VARCHAR(255),
  "price"      VARCHAR(255),
  "in_stock"   VARCHAR(255)
);
INSERT INTO "products" ("product_id", "price", "in_stock") VALUES ('101', '29.99', 'true');
INSERT INTO "products" ("product_id", "price", "in_stock") VALUES ('102', '15.50', 'false');
-- Tipp: Ändern Sie VARCHAR(255) vor dem Produktiveinsatz zu INT / DECIMAL(10,2) / BOOLEAN.

Einfache Anführungszeichen in Werten escapen

CSV:
id,note
1,O'Brien signed off
2,It's already done

SQL:
INSERT INTO `notes` (`id`, `note`) VALUES (1, 'O''Brien signed off');
INSERT INTO `notes` (`id`, `note`) VALUES (2, 'It''s already done');
Hinweis: Einfache Anführungszeichen werden verdoppelt (''), was dem SQL-Standard-Escape entspricht.

Typinferenz – INT vs. DECIMAL vs. TEXT

CSV:
user_id,score,bio
1,100,Hello
2,87.5,Long bio text...

Erkannte Typen (heuristisch):
  user_id -> INT
  score   -> DECIMAL(10,2)
  bio     -> VARCHAR(255)  (für längere Inhalte TEXT in Erwägung ziehen)

SQL-Vorschau:
INSERT INTO `students` (`user_id`, `score`, `bio`) VALUES (1, 100, 'Hello');
INSERT INTO `students` (`user_id`, `score`, `bio`) VALUES (2, 87.5, 'Long bio text...');

FAQ

Welche Art von SQL erzeugt das Tool?

Es erzeugt Standard-CREATE-TABLE plus INSERT-INTO-Anweisungen. Der Dialekt ist standardmäßig portables SQL – läuft mit kleinen Typanpassungen auf MySQL, PostgreSQL, SQLite und MSSQL. Manche Seiten lassen dich einen Zieldialekt für die Datentypen wählen (VARCHAR vs. TEXT, INT vs. INTEGER usw.).

Woher stammen die Spaltennamen?

Aus der ersten CSV-Zeile, wenn 'Erste Zeile ist Header' aktiv ist. Die Seite bereinigt Namen, indem sie Leerzeichen durch Unterstriche ersetzt und reservierte Wörter quotet. Ohne Header werden die Spalten zu col_1, col_2 usw.

Wie wird der Datentyp jeder Spalte erkannt?

Die Seite prüft Werte stichprobenartig und wählt den engsten passenden Typ: INTEGER, wenn alle Zellen ganze Zahlen sind, DECIMAL, wenn manche Brüche enthalten, VARCHAR(N) auf die längste Zelle dimensioniert, BOOLEAN für true/false, DATE/DATETIME für Strings im ISO-Format. Du kannst den erkannten Typ vor dem Generieren des SQL überschreiben.

Was ist mit Anführungszeichen und Sonderzeichen in den Daten?

Einfache Anführungszeichen in Strings werden durch Verdoppeln escaped (O'Brien → 'O''Brien'). Backslashes und Unicode-Zeichen werden buchstäblich durchgereicht – das entspricht PostgreSQLs Verhalten mit standard_conforming_strings = on. Prüfe das Ergebnis gegen MySQLs NO_BACKSLASH_ESCAPES-Modus, wenn du auf MySQL zielst.

Warum sind NULLs nicht dasselbe wie leere Strings?

Eine leere CSV-Zelle (z. B. 'a,,c') wird zu SQL NULL; ein quotierter Leerstring ('a,"",c') wird zu ''. Die Seite folgt dieser Konvention. Schalte 'Leer als NULL behandeln' ab, wenn du in beiden Fällen leere Strings erhalten willst.

Werden meine Daten hochgeladen?

Nein. CSV wird im Browser geparst und SQL dort erzeugt. Ein- und Ausgaben verlassen die Seite nie. Verwende das Ergebnis als SQL-Skript, das du selbst in deinen Datenbankserver importierst.

Sollte ich das erzeugte SQL auf einer Produktionsdatenbank einsetzen?

Erst prüfen. Die CREATE-TABLE-Anweisung passt eventuell nicht zu deinem bestehenden Schema; die INSERTs enthalten keine Constraints, Foreign Keys oder Indizes. Nutze es als Startgerüst, das du anpasst, vor allem für Primärschlüssel, NOT-NULL-Constraints und passende Datentypen.