Datendefinition der DB im Programm prüfen

[jobo]

<Schrott geschrieben, hab Dich mit Codehunter verwechselt>
.. welcher Versionsstand beim Kunden vorliegt und folglich, welche Alterscripte alle laufen müssten.
Da ist es dann schon spannend, nach einer -wie auch immer gearteten- Analyse, zu einem von n bekannten Ausgangszuständen zu kommen (Änderungen durch den Kunden selbst gibt es ja praktisch nicht).
Wenn es als n Ausganszustände gibt und 1 Zielzustand gibt, gibt es n-1 Alterscripte, die haargenau festgelegt sind, oder?
Wenn Du keine explizite Metainfo über die vorliegende Version gibt, reicht es evtl. anhand von Spaltenanalysen "Fingerabrücke" festzustellen, die den Stand wiedergeben.
Man spart sich also eine mglw. unsaubere Analyse der DDL und Differenz Script Generierung und baut im Labor die notwendigen, definierten, festen Alterscripte.
Dabei kann man dann noch überlegen, ob man (bei größeren Datenbewegungen) einige der Zwischenskripte zusammenfasst, um größere Sprünge in einem zu ermöglichen, also ganz alte Version in 2 Schritten auf aktuell, statt in 11 Schritten.

Interessant finde ich hier bei Firebird, wie es mit impliziten Commits (durch DDL) aussieht. Das macht jedes System anders und wenn man nicht Acht gibt, ist -zumindest bei unvorhergesehenen Ausgangslagen- das Kind schnell in den Brunnen gefallen.