SQL-Testdaten generieren: INSERT-Statements in Sekunden
Realistische Testdaten für SQL-Datenbanken erzeugen: Namen, Adressen, IBANs, Datumswerte – direkt als INSERT-Statement, bereit für MySQL, PostgreSQL und SQLite.
Für eine neue Tabelle schnell ein paar Hundert realistische Zeilen? Für einen Performance-Test ein paar Tausend? Für einen Demo-Dump mit deutschen Namen und Adressen? SQL-Testdaten zu erzeugen ist einer der häufigsten wiederkehrenden Entwickler-Jobs – und einer, bei dem man schnell Stunden verliert, wenn man es manuell macht.
Was realistische SQL-Testdaten ausmacht
Null-Dummy-Daten (Max Mustermann, Hauptstr. 1, 12345 Berlin) bestehen keinen echten Test. Für brauchbare Testdaten brauchst du:
- Variabilität in Namen, PLZ, Straßen und Städten
- Formatkonformität: gültige IBAN-Prüfziffern, korrekte PLZ-Länge, plausible Geburtsdaten
- Lokalisierung: deutsche Umlaute, Ländercodes, Telefonnummern-Format
- Keine echten Personen, aus DSGVO-Gründen
Vom Generator zum INSERT-Statement
Mit dem Testdaten-Generator erzeugst du einen Datensatz, z.B. 500 deutsche Kunden mit Name, Adresse, E-Mail, Telefonnummer und IBAN. Für den Import in deine Datenbank wandelst du den Export in ein INSERT-Statement um – entweder direkt im Generator oder per kurzer Transformation.
Beispiel: MySQL / MariaDB
INSERT INTO kunden (vorname, nachname, strasse, plz, ort, email, iban) VALUES
('Lukas', 'Weber', 'Lindenstraße 42', '10115', 'Berlin', 'lukas.weber@example.de', 'DE89370400440532013000'),
('Marie', 'Schmidt', 'Hauptplatz 7', '80331', 'München', 'marie.schmidt@example.de', 'DE12500105170648489890'),
('Jonas', 'Fischer', 'Am Markt 3', '20095', 'Hamburg', 'jonas.fischer@example.de', 'DE44100500000012345678');PostgreSQL (mit RETURNING)
INSERT INTO kunden (vorname, nachname, strasse, plz, ort, email, iban)
VALUES ($1, $2, $3, $4, $5, $6, $7)
RETURNING id;Für den Bulk-Import eignet sich bei Postgres auch COPY FROM aus einer CSV-Datei – schneller als viele einzelne INSERTs.
SQLite (via .read)
-- testdaten.sql
BEGIN TRANSACTION;
INSERT INTO kunden (vorname, nachname, email) VALUES ('Lukas', 'Weber', 'lukas.weber@example.de');
INSERT INTO kunden (vorname, nachname, email) VALUES ('Marie', 'Schmidt', 'marie.schmidt@example.de');
COMMIT;
-- Import
.read testdaten.sqlTypische Felder und Spalten
| Feld | Spaltentyp | Hinweis |
|---|---|---|
| Vorname / Nachname | VARCHAR(64) | UTF-8-Collation für Umlaute |
VARCHAR(254) | RFC-5321-Maximum | |
| PLZ (DE) | CHAR(5) | Als String, führende Nullen bewahren |
| IBAN | VARCHAR(34) | Max. 34 Zeichen laut ISO 13616 |
| Telefon | VARCHAR(32) | E.164-Format mit +49… |
| Geburtsdatum | DATE | Nicht als String speichern |
Formatierung und Konsistenz
Lange INSERT-Blöcke werden schnell unübersichtlich. Nutze unseren SQL-Formatter, um Statements vor dem Commit lesbar zu formatieren oder zu minifizieren. Für Migrationen hilft es außerdem, Testdaten in einem separaten seed.sql zu halten, damit sie nicht mit Schema-Migrationen kollidieren.
Testdaten vs. Produktionsdaten
- Nie Produktionsdaten für Tests kopieren – DSGVO-Verstoß vorprogrammiert.
- Nie reale IBANs einbauen, auch wenn sie dir „gehören" – generierte Fake-IBANs sind sicher.
- Deterministische Seeds helfen beim Debugging: Mit festem Seed produziert der Generator reproduzierbare Daten.
Praxis: Fülle eine Tabelle mit 1000 Zeilen
Workflow in unter 2 Minuten:
- Im Testdaten-Generator die gewünschten Felder auswählen (Name, Adresse, IBAN…).
- Anzahl auf 1000 setzen.
- Als SQL-INSERT exportieren.
- Mit dem SQL-Formatter aufräumen.
- In deine DB-Konsole einfügen und ausführen.
Das Ergebnis: realistische, aber harmlose Daten für dein Entwicklungs-, Staging- oder Demo-System – ohne das geringste DSGVO-Risiko.