Datenbank überprüfen und ggf. modifizieren

[Captnemo]

Hi Leute,

ich erzeuge aus meiner Anwendung heraus alle für die Anwendung benötigten Tabellen und Felder mit ihren benötigten Attributen (z.b. Feldtyp, Länge, Autoinc, Defaultvalue, NotNull, usw.).
Mein Anwendung soll aber nach jedem Update diese Datenbank anhand einer Referenz, die ebenfalls in der Anwendung vorhanden ist, prüfen, ob ggf. Ergänzungen oder Änderungen an den Tabellen, Feldern oder Indizes notwendig ist.

Zur Zeit mach ich das alles per Hand über "Show Tables", "Show Fields" bzw. "Show Index" und parse das Ergebnis quasi zu Fuß.
Aber die Anzahl der Tabellen ist mittlerweile um einiges angestiegen und damit natürlich auch die Anzahl der Felder und der Indizes, die es zu überprüfen gilt.

Die Prüfung ob eine Tabelle existiert oder eben nicht, ist nicht so aufwendig und funktioniert mit "Show tables" ausreichend. Das gleiche gilt für die Indezes.
Aber alle Felder der Tabelle zu prüfen, und halt auch ob ihre Attribute noch stimmen, ist schon um einiges aufwendiger.

Das Ziel ist klar. Bei jedem Update beim Kunden sollen neue Tabellen, Felder und Indizes hinzugefügt werden. Aber auch Veränderung von z.B. Feldlängen oder Feldattributen sollen zuverlässig umgesetzt werden. Und natürlich sollten nicht mehr benötigte Felder entfernt werden, damit keine Datenleichen rumliegen.

Ich wäre also für Anregungen dankbar, wie ich das mit den Felder Zeit-, Code- und Ressourcenschonend hinbekommen könnte. Vielleicht hat der eine oder andere von euch das bereit gemacht.

[jobo]

Hast Du denn einen Überblick, welche Versionen "draußen" sind? Oder ist es eher Wildwuchs?
Davon abhängig müsste man ein Verfahren finden.
Wenn Du aber bereits diese Referenzen nutzt, dann klingt das doch nach klaren Statusangaben, für die es dann jeweils ein festes Upgrade Script geben müsste.

[Sir Rufo]

@jobo

Ich erledige so etwas mit UpdateScripts. Dabei kann man nicht nur die Struktur verändern, sondern auch die Daten in den alten Tabellen in diese neue Struktur überführen (wenn es mal eine etwas größere Änderung gibt).

Delphi-Quellcode:

type
  IUpdateDatabase = interface
    [ '{3168C196-3301-4327-8135-C21378B17843}' ]
    function GetVersion( ): Integer;
    procedure ExecuteUpdateScript( const aScript: string );
  end;

  IUpdateStore = interface
    [ '{16A0E5BF-DC27-4D4C-A3D3-968F406C44B6}' ]
    function HasScriptFor( aVersion: Integer ): Boolean;
    function GetScriptFor( aVersion: Integer ): string;
  end;

  TDatabaseUpdater = class
  private
    FScriptStore: IUpdateStore;
  public
    constructor Create( const aScriptStore: IUpdateStore );

    function Update( const aDatabase: IUpdateDatabase ): Integer;
  end;

{ TDatabaseUpdater }

constructor TDatabaseUpdater.Create( const aScriptStore: IUpdateStore );
begin
  inherited Create;
  FScriptStore := aScriptStore;
end;

function TDatabaseUpdater.Update( const aDatabase: IUpdateDatabase ): Integer;
var
  lCurrentVersion: Integer;
  lScript        : string;
begin
  lCurrentVersion := aDatabase.GetVersion( );
  while FScriptStore.HasScriptFor( lCurrentVersion ) do
    begin
      lScript := FScriptStore.GetScriptFor( lCurrentVersion );
      aDatabase.ExecuteUpdateScript( lScript );
      lCurrentVersion := aDatabase.GetVersion( );
    end;
  Result := lCurrentVersion;
end;

end.

[bra]

Wir speichern eine Version irgendwo in der Datenbank und für jeden einzelnen Versionssprung gibt es ein Updateskript. So braucht man nur prüfen, welche Version der Kunde hat und alle nachfolgenden Updates der Reihe nach ausführen, bis man auf dem aktuellen Stand ist.

Alle Tabellen zu prüfen, was da wo drin ist, ist ja sonst ein Heidenaufwand und fehleranfällig ohne Ende.

[p80286]

Zitat von bra:

Wir speichern eine Version irgendwo in der Datenbank und für jeden einzelnen Versionssprung gibt es ein Updateskript. So braucht man nur prüfen, welche Version der Kunde hat und alle nachfolgenden Updates der Reihe nach ausführen, bis man auf dem aktuellen Stand ist.

Das sollte im Prinzip der übliche Weg sein.
Falls aber Wildwuchs vorhanden ist gibt es zwei Möglichkeiten
a) Radikal jede Installation in einen definierten Zustand bringen, und dann die notwendigen Updates durchführen
b) Die Tabellen und Spalten die bekannt sind bearbeiten, und alle anderen zusätzlichen Tabellen und Spalten ignorieren, soweit möglich.

Gruß
K-H

[Der schöne Günther]

Mache ich auch so. Vor dem ersten mal hatte ich mich ziemlich gefürchtet, dann aber gemerkt dass es eigentlich total einfach ist:

1. Die Datenbank enthält immer eine Versionsinformation, z.B. einfach nur eine Tabelle mit dem Eintrag "1.3"
2. Die Software braucht eine bestimmte Version. Zum Beispiel "1.5"
3. Beim Start wird geschaut ob die Datenbank in der notwendigen Version vorliegt:
4. Ist die Version "1.3"? Dann führe das Update-Script von 1.3 auf 1.4 aus
5. Ist es "1.4"? Dann führe das Update-Script von 1.4 auf 1.5 aus

Klappt super. Zumindest habe ich noch von keinem Kunden gehört dass plötzlich alle seine Daten weg seien

(Ich mache trotzdem vorher ein Backup. Wenn der Platz nicht ausreicht schreit das Programm um Hilfe)

[Sir Rufo]

So ein Update sollte (wenn möglich) immer in einer Transaktion laufen und/oder mit einer Datensicherung (die der Kunde laut Vertrag eh immer machen muss )

Wenn man möchte, kann man mit fortschreitenden Versionsnummern auch Updatescripts anbieten, die einen größeren Versionssprung machen.

Die muss man allerdings auch wieder testen ... ist also eher theoretisch (funktionieren würde es aber )