Mailinglisten-Archive |
Habe leider gestern nicht mehr geantwortet, da ich einen Notfall bei einem Kunden hatte :-( > 1. Wie du's schon machst: ASCII Dump fahren und den archivieren > 2. Binärdump fahren und über einen CVS Wrapper archivieren > 3. Basis-Version als ASCII Dump archivieren und dazu einen Baum der > DB-Migrationsscripte, also der Scripte die die bestehende DB auf den > neuen Stand patchen. Das sind auch die Möglichkeiten die mir eingefallen sind. Dabei ist Methode 3 die einzig vernünftige, was Rückverfolgung von Änderungen und das Auftreten von Seiteneffekten möglichst verhindert. Nur verlangt das, wie schon gesagt, einen sehr großen Aufwand und zudem sollten die Entwickler auch das manuelle Schreiben von DBA Scripten beherschen und nicht nur in DBA Stdiios herumklicken können. Die Methode funktioniert allerdings nicht mit Objekten, wie Stored Procedures, Packages und ähnlichem. Dort muß man den Source code exportieren und wie ein 'gewöhnliches' PHP Script im cvs behandeln. Insgesamt, beinhaltet die Methode aber ein sehr großes Potetial an Fehlermöglichkeiten, da der Entwickler sich immer bewußt sein muß nach jeder Änderung, sobald sie getestet ist, diese ins cvs zu stellen. Meistens, so habe ich die Erfahrung gemacht, werden Änderungen in der Datenbank parallel zu Änderungen in der Applikation gemacht und der Entwickler muß sich die Änderungen in der Datenbank mitschreiben, damit er sie auch nicht vergißt, sobald er die neue Version ins cvs released. Ziel ist es ja eine definierte Version der Applikation mit der dazugehörenden funktionierenden Version der Datenbank zu haben und diese einander zuordnen zu können. Gruß Leonhard
php::bar PHP Wiki - Listenarchive