Lokale Datenbanken und Versionsverwaltung

[Nersgatt]

Zitat von mkinzler:

Datenbanken haben in der Versionsverwaltung nichts zu suchen, es sei den es handelt sich nur um eine Strukturvorlage

Prinzipiell stimme ich zu. Strukturvorlagen werden bei mir aber in Form von Scripten abgelegt.
Eine Ausnahme stellen für mich Datenbanken dar, die für Unittests als Testcase benötigt werden. Aber das sind ja sehr spezielle Datenbanken, die sich nicht ständig ändern.
Reine Testdaten (z.B. Kundendaten), etc. gehören aber für mich auch nicht in die Versionverwaltung.

[Der schöne Günther]

DDL, klar, das muss versioniert werden.

Die reinen Daten? Habe ich auf meiner GUI eine Ansicht "Die letzten zwei Wochen" dann brauche ich natürlich auch Daten um mir dort etwas anzeigen zu lassen.

Wovor ich mich halt "fürchte" ist: Würde man diese Daten nicht im Repo mitschleppen ist der Fall gegeben, die Dinge schlichtweg zu "vergessen" für unterwegs mitzunehmen, irgendwo hin zu packen und ggf Konfigurationen anzupassen.

Oder halt immer Daten dafür auf Halde liegen hat, irgendwann ändert sich etwas an der Struktur und ich habe seit Monaten alte Daten auf der Platte liegen die mittlerweile nicht mehr passen.

[mkinzler]

Dann erzeuge die eine "Populate"-Skript und packe dies in Repo

[Uwe Raabe]

Zitat von Der schöne Günther:

Die reinen Daten? Habe ich auf meiner GUI eine Ansicht "Die letzten zwei Wochen" dann brauche ich natürlich auch Daten um mir dort etwas anzeigen zu lassen.

Die wären aber zwei Wochen später auch nicht mehr sichtbar.

In diesem Fall wäre ein Datengenerator sinnvoller, der zumindest nach jedem Checkout und dann bei Bedarf einen passenden Datenbestand anlegt.

[Der schöne Günther]

Ja, ich glaube in die Richtung bewegen wir uns langsam...

Ich würde das aber nicht ans Checkout hängen- Nicht nur weil ich mit solchen Triggern noch nie gearbeitet habe, sondern weil ich im eigentlichen Programm da wenigstens noch debuggen und Einfluss nehmen kann, wie das alles "populated" wird.