Hallo zusammen,
wir haben hier eine von unseren größeren Anwendungen die eine Postrgesql Datenbank benutzt, an der aber noch viel entwickelt wird. Um diese zu Versionieren exportieren wir die Daten und Strukturen als SQL File und packen das ganze ins Git. Ich perönlich finde das ganze sehr umständlich da es auch gerne mal vergessen wird. Wie haltet Ihr das ? Gibt es da was einfacheres ? Eigentlich träume ich davon unserem Jenkins diese Aufgabe zu geben. Hat das schon mal jemand gemacht ?

Moin...
So ein Problem hatte ich auch. Unsere DB hat 3GB (ZIP 300MB)...zu viel für GIT.

Ich habe mich entschlossen, die DB in einem separatem Order abzulegen und im GIT nur den Link auf die Datei. Der Dateiname sollte dann das Datum oder die Revision incl. der DB Version haben.

PS:
Es erleichtert es ungemein, wenn man die DB Version in der Datenbank speichert. (Tabelle Version)

Die Struktur welche die DB haben soll liegt doch in Quellcode oder Konfigurationsdateien vor.
Einfach diese Sichern.

Bei vielen Daten (wie bei haentschman) wird man wohl die diversen Stände im Netzwerk ablegen mit entsprechenden Verzeichnisnamen.
Und dieses "vergessen" muss halt durch entsprechende Vorgaben (Reviewprozess, ...) abgesichert werden.

Ich würde nur die Änderungsskripten für die DB versionieren. Man muß halt einmal einen Stand festlegen, ab dem das dann greift und ab dann muß jeder Entwickler seien Änderungen an der DB als (wiederholt ausführbares!) Skript erstellen und dieses in die Versionsverwaltung einspielen.
Wird eine neue Version erstellt, dann werden alle diese Skripten zu einem einzigen zusammengefaßt (wegen Performance bei mehrfachen Änderungen an ein und der selben Procedure) und dieses gegen eine Referenzdatenbank mit dem alten Stand laufen gelassen.
Achtet auf das wiederholt ausführbar: das Einzel-Skript muß erkennen, ob es schon einmal gegen die DB gelaufen ist und darf bei erneutem Aufruf nichts tun. Hintergrund: es gibt nichts Ekelhafteres, als wenn ein Teil der Skripten schon gelaufen ist und dann z.B. die Verbindung zur DB abgebrochen ist, so daß ein inkonsistenter Stand existiert. Bei großen Änderungen wird es dann extrem aufwendig, hereauszufinden, was schon da ist und was nicht und welches Teilskript man nochmal laufen lassen muß.
Auch für neue Stammdaten: diese ebenfalls nur per Skript erstellen und dieses in die Versionsverwaltung einpflegen.

Das Vergessen dürfte das Problem sein. Das ist auch bei neuem Programm Code schlecht.
- DDL Scripte versionieren und systematisch prüfen
- DML Scripte versionieren und systematisch prüfen
- große (Test)Datenmengen idealerweise generieren (geht super in PG)

Am Schluss muss z.B. ein nächtlicher Build auch über Jenkins gelingen, sowohl from Scratch, als auch von der letzten Version (Create versus Alter DDL).

Schaue dir Liquibase oder Flyway an.

Wir arbeiten mit Oracle und PL/SQL und haben letztlich das gleiche Problem (ok, mein Chef sieht das ein wenig anders ). Wir verwenden TFS (Microsoft) für die Versionierung/Quelltextverwaltung. Das funktioniert aber eher recht rudimentär.

Allerdings verwenden wir für die Datenmodellierung ER/Studio (Embarcadero), so das wir für diesen Teil nur eine Datei für haben. Das lässt sich somit relativ einfach über TFS (oder in deinem Fall GIT) recht einfach handhaben.

Erst einmal Danke für Eure Antworten. Ich werde mir die mal in Ruhe anschauen.

Moin...

Zitat:

so das wir für diesen Teil nur eine Datei für haben. Das lässt sich somit relativ einfach über TFS (oder in deinem Fall GIT) recht einfach handhaben.

...

Zitat:

...exportieren wir die Daten und Strukturen als SQL File und packen das ganze ins Git.

Zitat von haentschman:

...

Zitat:

...exportieren wir die Daten und Strukturen als SQL File und packen das ganze ins Git.

Bei mir wäre es andersrum. Ich hätte die Strukturdefinition und die Daten in SQL File, das auf Abruf Tabellen erzeugt und Inhalte einträgt.
Diese SQL Files gehören in die Sourcecode Verwaltung.