Dummy Database Generator – Testdatenbanken mit Beziehungen erstellen

Inhaltsverzeichnis

             Schnellübersicht
            Dummy Database Generator: Testdatenbank mit mehreren Tabellen
Presets: Shop, Blog, CRM, Schulverwaltung, Bibliothek
Beziehungen: Foreign Keys zwischen Tabellen
Export: SQL (MySQL/PostgreSQL/SQLite), JSON, CSV, DBML
Schema-Viewer: Tabellen mit Spalten und Typen
Theorie: Was sind Testdatenbanken? (Anfängerfreundlich)
Geschichte: Von Seed-Skripten zu Faker & Co.
FAQ: Häufige Fragen zu Dummy-Datenbanken

        

1. Dummy Database Generator

Wähle ein Preset oder konfiguriere eigene Tabellen – die Datenbank wird sofort generiert.

Datenbank-Preset wählen

Einstellungen

Datensätze pro Tabelle 5 bis 500 Datensätze pro Tabelle

SQL-Dialekt

Daten-Sprache

Zufalls-Seed Für reproduzierbare Daten

Schema-Vorschau

Ausgabe

// Klicke auf "Neu generieren", um Daten zu erstellen

Wussten Sie schon?

Eine Testdatenbank ist essentiell für realistische Tests – ohne sie testet man oft nur mit leeren Tabellen.
Foreign Keys stellen sicher, dass Beziehungen zwischen Tabellen gültig sind.
DBML (Database Markup Language) wird von Tools wie dbdiagram.io verwendet, um ERDs zu erstellen.
Moderne Tools wie Faker, Mockaroo oder Redgate SQL Data Generator erzeugen realistische Testdaten.
Seed-Werte erlauben reproduzierbare Tests – wichtig für CI/CD-Pipelines.

2. Theorie – Testdatenbanken einfach erklärt

Verstehe die Grundlagen von Testdatenbanken – ohne Vorkenntnisse.

Was ist eine Dummy-Datenbank?

Eine Dummy-Datenbank (Testdatenbank) ist eine Datenbank mit künstlich erzeugten Daten:

Realistisch: Format wie echte Daten
Synthetisch: Keine echten Personen
Vollständig: Mehrere Tabellen mit Beziehungen
Reproduzierbar: Mit Seed-Werten

users, orders, products, categories

Warum Testdatenbanken?

Sie sind aus der Entwicklung nicht wegzudenken:

Entwicklung: Realistische Daten zum Arbeiten
Testing: Edge-Cases und Mengentests
Demos: Überzeugende Präsentationen
Performance: Last-Tests mit vielen Datensätzen
DSGVO: Keine echten Kundendaten verwenden

Aus 20 Datensätzen werden 1 Million

Beziehungen (Foreign Keys)

Eine gute Testdatenbank hat Beziehungen zwischen Tabellen:

1:n: Ein Kunde → viele Bestellungen
n:m: Bestellung ↔ Produkte
1:1: Benutzer → Profil
Referenzielle Integrität: Fremdschlüssel müssen existieren

orders.customer_id → customers.id

Tipps für Testdaten

Seed verwenden: Reproduzierbare Tests
Reihenfolge: Erst Parent, dann Child
Edge-Cases: Leere Strings, Sonderzeichen
Keine echten Daten: DSGVO!
Faker: Nicht selbst Namen erfinden

INSERT INTO users ...; INSERT INTO orders ...

Wussten Sie schon? Die bekannteste Bibliothek für Testdaten heißt Faker und wurde ursprünglich 2010 für Ruby entwickelt. Heute gibt es sie für Python, JavaScript, PHP, Java, Perl, Rust und mehr. In Python produziert fake.name() einen zufälligen Namen, fake.iban() eine gültige IBAN. Besonders clever: Mit FactoryBoy (Python/Django) oder Alice (PHP/Symfony) können auch komplexe Datenbankbeziehungen automatisch generiert werden. Die Idee: Ein Objekt wird erstellt und alle Abhängigkeiten werden automatisch mit-generiert.

3. Typische Datenbank-Schemas

Diese Schemas werden in unserem Tool als Presets angeboten:

Online-Shop

Klassisches E-Commerce-Schema:

customers: Kunden
categories: Produktkategorien
products: Produkte mit Kategorie-FK
orders: Bestellungen mit Kunden-FK
order_items: Positionen mit Bestell- und Produkt-FK

customers → orders → order_items → products

Blog / CMS

Content-Management-Schema:

users: Autoren
categories: Blog-Kategorien
posts: Beiträge mit Autor und Kategorie
comments: Kommentare mit Post-FK
tags: Schlagwörter

users → posts → comments

CRM-System

Customer-Relationship-Management:

companies: Firmen
contacts: Ansprechpartner mit Firmen-FK
deals: Verkaufschancen mit Kontakt-FK
activities: Aktivitäten (Calls, Meetings)

companies → contacts → deals → activities

Schulverwaltung

Educational Management:

students: Schüler
teachers: Lehrer
courses: Kurse mit Lehrer-FK
enrollments: Anmeldungen (Student + Kurs)
grades: Noten mit Enrollment-FK

students ↔ courses (n:m via enrollments)

4. Geschichte der Testdaten-Generierung

Von handgeschriebenen SQL-Skripten zu intelligenten Generator-Bibliotheken.

1970er

Erste Testdaten

In den Anfängen der Datenbankentwicklung wurden Testdaten per Hand in SQL-Skripten geschrieben. Meist einfache Werte wie "test1", "test2", "test3" – kaum realistisch.

1980er

Datenbank-Tests

Mit dem Aufstieg relationaler Datenbanken (Oracle, DB2) wurde das Testen komplexer. Entwickler begannen, SQL-Skripte zur Massengenerierung mit Schleifen zu schreiben.

2001

Ruby Faker

Die Bibliothek Faker wird für Ruby veröffentlicht. Erstmals können realistische Namen, Adressen und Telefonnummern automatisch generiert werden – ein Meilenstein.

2008

Python Faker

Python-Faker wird populär. Die Bibliothek unterstützt 40+ Sprachen und hunderte Datentypen. Wird zum Standard für Testdaten in der Python-Community.

2012

Mockaroo & Online-Tools

Webbasierte Tools wie Mockaroo und Generatedata.com werden populär. Nutzer können Testdaten ohne Programmierung im Browser generieren und als SQL/CSV exportieren.

2015

Factory-Muster

FactoryBoy (Python/Django) und Alice (PHP/Symfony) revolutionieren die Testdaten-Generierung: Komplexe Beziehungen werden durch Sub-Factories automatisch aufgebaut.

Heute

KI-gestützte Generierung

Künstliche Intelligenz revolutioniert die Testdaten-Generierung: Sprachmodelle können realistische Texte, konsistente Beziehungen und DSGVO-konforme synthetische Daten erstellen. Tools wie Tonic.ai und Mostly AI anonymisieren Produktionsdaten für Tests.

5. FAQ – Spannende Fragen & Antworten

Häufige Fragen zu Dummy-Datenbanken

Was ist der Unterschied zwischen Testdaten und Produktionsdaten?

Die beiden Datentypen haben grundlegend unterschiedliche Zwecke:

Aspekt	Testdaten	Produktionsdaten
Zweck	Tests, Entwicklung	Echter Betrieb
Personen	Fiktiv	Echt
Rechtliches	Kein Datenschutz	DSGVO-konform
Umgebung	Dev / Test / Stage	Production
Backup	Nicht nötig	Pflicht
Zugriff	Alle Entwickler	Stark eingeschränkt
Konsistenz	Kann inkonsistent sein	Muss konsistent sein

Warum keine Produktionsdaten für Tests?

DSGVO: Strafen bis 20 Mio. € oder 4% des Umsatzes
Sicherheit: Testsysteme sind oft weniger geschützt
Zugriff: Mehr Entwickler haben Zugang
Lecks: Bekannte Vorfälle bei Fintech, Health-Tech, etc.

Ausnahme: Anonymisierte Produktionsdaten sind in manchen Fällen erlaubt – aber Vorsicht, Anonymisierung ist schwer!

Wie stelle ich referenzielle Integrität sicher?

Referenzielle Integrität bedeutet: Jeder Foreign Key verweist auf einen existierenden Primary Key.

Reihenfolge beim Einfügen:

Elterntabellen zuerst: customers, products, categories
Dann Kindtabellen: orders, order_items
Zuletzt Verknüpfungstabellen: bei n:m-Beziehungen

Unser Tool macht das automatisch:

Sortierung: Tabellen werden topologisch sortiert
Zufällige FKs: Verweisen immer auf existierende PKs
Verteilung: Realistische 1:n-Verhältnisse

Beispiel:

-- 1. Erst Kunden
INSERT INTO customers (id, name) VALUES (1, 'Max');

-- 2. Dann Bestellungen mit gültigem FK
INSERT INTO orders (id, customer_id, total) VALUES (1, 1, 99.99);

-- 3. Nie umgekehrt!
-- INSERT INTO orders (id, customer_id) VALUES (1, 999); -- FEHLER!

Bei zufälligen FKs:

Unser Tool wählt eine zufällige existierende ID aus
Verteilt Bestellungen auf realistische Weise (manche Kunden bestellen mehr)
Prüft Konsistenz (z.B. Bestelldatum nach Kundenerstellung)

Was ist DBML und wofür brauche ich das?

DBML (Database Markup Language) ist eine textbasierte Sprache zur Beschreibung von Datenbankschemas:

Hauptzweck:

ERD-Visualisierung: Automatische Diagramme
Teamarbeit: Gemeinsame Schema-Definitionen
Versionierung: Schema im Git
Code-Generierung: SQL, ORM-Modelle

Beispiel-Syntax:

Table customers {
  id integer [primary key]
  name varchar
  email varchar [unique]
}

Table orders {
  id integer [primary key]
  customer_id integer [ref: > customers.id]
  total decimal
}

Tools:

dbdiagram.io: Online-Editor für DBML
dbdocs.io: Dokumentation aus DBML
DBeaver: Import von DBML
VSCode Extension: Syntax-Highlighting

Vorteile gegenüber SQL:

Kompakter: Nur das Schema, keine Daten
Lesbarer: Auch für Nicht-SQL-Experten
Visualisierbar: Direkt als ERD

Unser Tool exportiert das Schema als DBML – du kannst es direkt in dbdiagram.io einfügen und ein ERD generieren lassen.

Wie viele Datensätze brauche ich für aussagekräftige Tests?

Die optimale Anzahl hängt vom Testziel ab:

Testart	Datensätze	Zweck
Unit-Tests	5-20	Einzelne Funktionen
Integration	50-200	Zusammenspiel
E2E	100-1000	Komplette Workflows
Load-Tests	1M+	Performance
ML-Training	10K+	Modelle trainieren

Faustregeln:

Unit-Tests: 3-5 typische Fälle + Edge-Cases
Integration: Genug für realistische Szenarien
UI-Tests: Auch längere Texte, Sonderzeichen
Performance: Produktionsmenge × 1,5

Für die Entwicklung typisch:

Prototyp: 10-20 Datensätze pro Tabelle
Standard-Dev: 50-100 pro Tabelle
Vollständiger Test: 500-1000 pro Tabelle

Qualität > Quantität: 100 gut gewählte Testdaten sind besser als 10.000 zufällige. Wichtig ist die Abdeckung von Edge-Cases:

Leere Werte: "", null, undefined
Sehr lange Werte: 10.000 Zeichen
Sonderzeichen: Emojis, Unicode
Grenzwerte: 0, -1, MAX_INT

Wie importiere ich die Daten in meine Datenbank?

Der Import hängt von deinem Datenbanksystem ab:

MySQL / MariaDB:

mysql -u root -p meine_datenbank < dump.sql

# Oder interaktiv:
mysql -u root -p
source /pfad/zu/dump.sql;

PostgreSQL:

psql -U postgres -d meine_datenbank -f dump.sql

# Als Superuser:
sudo -u postgres psql meine_datenbank < dump.sql

SQLite:

sqlite3 meine_datenbank.db < dump.sql

# Oder direkt:
sqlite3 meine_datenbank.db
.read dump.sql

MS SQL Server:

sqlcmd -S localhost -U sa -P passwort -d meine_db -i dump.sql

# Oder in SSMS:
# File → Open → File → Ausführen

Programmatisch (Node.js):

const mysql = require('mysql2/promise');
const fs = require('fs');

const sql = fs.readFileSync('dump.sql', 'utf8');
const conn = await mysql.createConnection({...});
await conn.query(sql);

Mit Docker:

docker exec -i mysql-container mysql -u root -p passwort meine_db < dump.sql

Tipp: Bei großen Dateien (> 100 MB) vorher Transaktionen deaktivieren und Bulk-Inserts nutzen.

Welche Tools gibt es für Testdatenbanken?

Eine Auswahl beliebter Tools nach Kategorie:

Programmbibliotheken:

Faker (Python, JS, PHP, Ruby, Java)
Mockaroo (Web + API)
FactoryBoy (Python/Django)
Alice (PHP/Symfony)
Mimesis (Python, sehr schnell)

Desktop-Tools:

Redgate SQL Data Generator (kommerziell)
dbForge Data Generator (SQL Server, MySQL)
Datanamic Data Generator
EMS Data Generator (mehrere DBs)

Online-Tools:

Mockaroo.com – 100+ Datentypen, SQL/CSV/JSON-Export
Generatedata.com – Kostenlos, umfangreich
FillDB.com – Für MySQL/PostgreSQL

KI-basierte Tools (synthetische Daten):

Tonic.ai – Anonymisiert Produktionsdaten
Mostly AI – KI-generierte synthetische Daten
Hazy – Datenschutz durch synthetische Daten
Gretel – Datenschutz-konforme Daten

Datenbank-spezifische Tools:

SSDT (SQL Server Data Tools) – Data Generation Plan
Oracle SQL Developer – Data Generator
PostgreSQL Anonymizer – Daten-Anonymisierung
Liquibase – Seed-Data-Management

Unser Tool konzentriert sich auf komplette Datenbanken mit Beziehungen – was viele einfache Tools nicht können.

Was ist der Unterschied zwischen Seed und Fixture?

Die beiden Begriffe kommen aus dem Test-Driven Development und haben unterschiedliche Bedeutungen:

Aspekt	Seed	Fixture
Zweck	Datenbank füllen	Testdaten definieren
Wann	Vor App-Start	Vor jedem Test
Persistenz	Bleibt bestehen	Wird neu geladen
Umfang	Groß (100-10.000)	Klein (1-20)
Beispiel	Kategorien, Währungen	Testbenutzer

Seeds:

Definition: Grundlegende Daten für die Anwendung
Beispiele: Länder, Währungen, Kategorien, Admin-User
Werden einmalig beim Setup eingefügt
Verändern sich nicht während Tests

Fixtures:

Definition: Testdaten für einen bestimmten Test
Beispiele: "Ein Benutzer mit Admin-Rechten"
Werden vor jedem Test neu geladen
Datenbank wird oft zurückgesetzt

Beide sind wichtig:

Seeds: Für die App-Grundlage
Fixtures: Für saubere Tests
Dummy Database: Für Entwicklung und Demos

Unser Tool generiert Daten für alle drei Zwecke: Große Mengen für Seeds, Tests und Entwicklungsumgebungen.

Wie teste ich mit verschiedenen Datenbank-Dialekten?

Verschiedene Datenbanksysteme haben unterschiedliche SQL-Dialekte:

Wichtige Unterschiede:

Feature	MySQL	PostgreSQL	SQLite
Strings	'text' oder "text"	Nur 'text'	'text'
Auto-Increment	AUTO_INCREMENT	SERIAL	AUTOINCREMENT
Boolean	TINYINT(1)	BOOLEAN	INTEGER
Datetime	DATETIME	TIMESTAMP	TEXT
Limits	LIMIT n OFFSET m	LIMIT n OFFSET m	LIMIT n OFFSET m
Identifier	`backticks`	"double quotes"	"double quotes"

Unser Tool generiert SQL passend zum gewählten Dialekt:

MySQL: Backticks, AUTO_INCREMENT
PostgreSQL: Double Quotes, SERIAL
SQLite: AUTOINCREMENT, INTEGER PRIMARY KEY
MS SQL: IDENTITY, Brackets

Für Multi-DB-Tests:

Docker Compose: Mehrere DBs parallel
Testcontainers: Dynamische Test-DBs
ORMs: Kümmern sich um Dialekte (Hibernate, Sequelize, SQLAlchemy)
Migrations: Flyway, Liquibase, Alembic

Beispiel Docker Compose:

services:
  mysql:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: test
  postgres:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: test

Zusammenfassung

Die wichtigsten Punkte

Dummy-Datenbank: Realistische Testdaten mit mehreren Tabellen
Beziehungen: Foreign Keys mit referenzieller Integrität
Reihenfolge: Erst Parent, dann Child beim Import
Seed-Werte: Für reproduzierbare Tests
DSGVO: Nie echte Daten – immer synthetische Daten
Export: SQL (MySQL/PostgreSQL/SQLite/MSSQL), JSON, CSV, DBML
DBML: Für ERD-Visualisierung in dbdiagram.io
Tools: Faker, FactoryBoy, Mockaroo, Tonic.ai
Unser Tool: Komplette Datenbanken mit Beziehungen generieren

Weitere Tools

Datengenerierung

Generiere allgemeine Testdaten mit vielen Kategorien.

Zum Tool

AD CSV Generator

Erstelle AD-Testdaten für Windows-Server-Importe.

Zum Tool

JSON Editor

JSON formatieren, validieren und visualisieren.

Zum Tool

Hash Generator

MD5, SHA-1, SHA-256 und SHA-512 für Text und Dateien.

Zum Tool