Testdatenbank vs. Produktivsystem – wie trenne ich das sauber im Projekt?

Hallo Anna, das Problem kenne ich noch gut aus meinem ersten Projekt – man denkt am Anfang "ist doch eh nur eine Handvoll Datensätze" und am Ende ist alles vermischt. Für den Rahmen eines Semesterprojekts braucht ihr wirklich keine komplette Serverlandschaft, mehrere Datenbankinstanzen plus saubere Konfigurationstrennung reichen völlig aus.

So würde ich es aufbauen:

• Pro Umgebung eine eigene Datenbank – z. B. projekt_dev, projekt_test, projekt_prod. Über Docker ist das schnell erledigt, ihr könnt auch einfach mehrere Container oder bei lokalen DBs mehrere Schemas anlegen.
• Die Connection-Strings landen nicht hartcodiert im Code, sondern in Umgebungsvariablen (z. B. über eine .env-Datei, die nicht ins Repository eingecheckt wird). So lädt eure Anwendung je nach Umgebung automatisch die passende Verbindung.
• Für das Produktivsystem nur noch Migrationsskripte laufen lassen (z. B. mit einem Migrationstool eurer Wahl), keine manuellen Testinserts mehr.

Typischer Fehler, den wir auch gemacht haben: Testdaten "mal eben schnell" direkt per SQL in die Produktiv-DB schreiben, weil es gerade praktisch war. Das rächt sich garantiert. Merksatz, den ich mir seitdem gebe: Produktivdaten werden nie manuell angefasst, sondern nur über Anwendung oder Migration verändert.

Mit dieser Minimal-Lösung – getrennte DBs plus Env-Variablen – habt ihr schon 90 % des Nutzens einer "echten" Umgebungstrennung, ohne dass ihr dafür extra Server aufsetzen müsst.

Daniels Antwort trifft es schon ziemlich gut, ich ergänz noch den Punkt Seed-Daten, den finde ich mindestens genauso wichtig wie die Trennung selbst.

Bei uns läuft das so: Migrations-Skripte bauen nur die Struktur auf (Tabellen, Indizes, Constraints), und separat davon gibt es Seed-Skripte, die Testdaten einspielen. Die beiden Dinge sollte man strikt trennen. Vorteil: Ihr könnt eure Dev- oder Test-DB jederzeit komplett wegschmeißen und per Skript neu aufbauen – Struktur rein, dann Seed-Daten rein, fertig. Kein manuelles Rumgefummel mehr, keine Altlasten.

Praktisch sieht das bei uns meistens so aus:

• ein Ordner "migrations" mit durchnummerierten Skripten (Schema-Änderungen, versioniert)
• ein Ordner "seeds" mit Testdaten, die nur in Dev/Test ausgeführt werden, niemals in Prod
• ein kleines Setup-Skript oder Makefile-Target, das beides nacheinander anstößt

Für die Produktivumgebung gibt's dann nur die Migrationen, nie die Seeds. Das verhindert genau euer Problem, dass Testdaten und echte Daten sich vermischen.

Merksatz: Struktur kommt aus Migrationen, Inhalte zum Testen kommen aus Seeds – und beide Quellen laufen nie gemeinsam gegen die Produktiv-DB. Typischer Anfängerfehler ist, Seed-Daten einfach als "Teil der Migration" mit reinzuschreiben, das rächt sich spätestens beim Deployment.