Strategie - Update Skripte

Hi,

unsere Applikation ist inzwischen ein paar Versionen gealtert und es hat sich dementsprechend auch die Datenbank hier und da geändert (Tabellen/Spalten sind hinzu gekommen/gelöscht worden usw.).
Bisher habe ich immer überprüft, ob eine einzelne Tabelle/Spalte existiert und habe dementsprechend die Tabelle geändert, so dass ich unser Update Skript über jede beliebige Datenbank-Version laufen lassen konnten, um sie auf den aktuellen Stand zu bringen. Nur mittlerweile wird das ein wenig ... unübersichtlich.
Da wollte ich einmal bei Euch nachfragen, wie ihr das denn so handhabt. Ich hab da bisher 2 Ideen, die mir das Leben wahrscheinlich schon bedeutend erleichtern könnten, aber ich kann mir vorstellen, dass sich jemand da schon bedeutend mehr und bessere Gedanken drum gemacht hat.

1. Erstmal alle Funktionen, dann stored procedure und dann Views löschen um schon mal alle Abhängigkeiten zu den Tabellen entfernen, damit beim Ändern der Tabellen keine Konflikte erstehen und dann am Ende des Update-Skripts wieder alle Abhängigkeiten hinzufügen.
Bei uns steht da halt alles kreuz und quer vermischt drin, da am Anfang versucht worden ist die entsprechenden Views/Prozeduren/Funktionen, die eine Tabelle verwenden, auch im Skript zu der Tabelle zu schreiben.

2. Nicht mehr ein Update Skript für alle Versionen erstellen, sondern eine Aneinanderreihung von Update Skripten erstellen, so dass

UpdateSkript|Programversionen
Update1.sql | 1.0 -> 1.1
Update2.sql | 1.1 -> 1.2
...
Update1001.sql: 9.1001 -> 9.1002

immer ein Update Skript von einer festen Version auf die nächst folgende Version updatet. Nur hat man dann nicht am Ende 1001 Update Skripte? Und wenn eine Tabelle geändert werden muss in der sehr viele Daten enthalten sind, kann das ja schon mal ein wenig Zeit kosten. Da würde ich es halt vorziehen, wenn ich die Tabelle nur ein einziges Mal ändern müsste (mit den 1001 Update Skripten kann es ja sein, das die Tabelle (theoretisch) in jedem Update Skript geändert werden muss).

Also ... ich habe keinen Plan, wie man dies nun am besten aufzieht. Für jedweden Tip/Gedankenanstoss bin ich dankbar.

Ich empfinde die Idee mit der Aneinanderreihung von Update-Skripten für geeignet, da du dort die Übersicht bewahren kannst.

Den Nachteil, dass es lange dauern kann, kann ich im ersten Moment verstehen, aber im zweiten Moment frage ich mich:
Wie schlecht muss eine Software geplant sein, damit so viele Änderungen notwendig sind, dass es zeitintensiv wird?

Erstmal Danke für die Antwort.

Mit deinem Einwand hast Du natürlich Recht. Aber ich gehe da einmal von dem worst-case Szenario aus. Das ist halt der Punkt ... diesmal wollte ich mit ein wenig Planung an die SQL-Skripte und deren Neustrukturierung ran und wissen, was mich in den nächsten Jahren womöglich erwarten wird

Um dort ein wenig Zeit einzusparen (mal angenommen man will von Version 8 auf Version 42 updaten), hatte ich mir überlegt später auch Update-Skripte zu generieren, die über mehrere Version gehen. Ungefähr so ...

8 -> 9
9 -> 10
10 -> 20
20 -> 30
30 -> 40
40 -> 41
41 -> 42

Das wird jetzt am Anfang wohl noch nicht nötig sein, da sich unsere Datenbank meistens eh nur in Kleinigkeiten ändert. Aber man weiss ja nie

witte

Also ich sammele die Änderungen immer in einem SQL-Skript und wenn dann eine neue Softwareversion ausgeliefert wird gebe ich dem Skript eine Versionsnummer und liefere sie mit aus (das kann dann über ein Tool eingespielt werden). Danach fange ich ein neues leeres SQL-Skript für die nächste Version an. Wenn dann der Mitarbeiter zu einem Kunden fährt um dort alle Systeme zu aktualiseren baue ich ihm meistens ein Diff-File wo alle ausstehende Updateskripte zusammenkopiert worden sind. Das passiert aber eigentlich selten, da die Kunden meist die aktuelle Software- und damit DB-Version haben wollen, es gibt z.B. keine großen Versionsunterschiede zwischen den einzelnen Kunden. Worauf du lieber aufpassen solltest ist die Möglichkeit
* ein Skript mehrmals einzuspielen ohne das dieses schädlich ist
* der häufigste Fehler ist ist das Auslassen (Vergessen) ein Skript einzuspielen. Diese Fehler lassen sich nur schwer finden. Hier solltest du irgend eine Art Management einführen.