'loha Folks,

ich wollte mich erkundigen, wie Datenbank Updates grundsätzlich gehandhabt werden. Mit Update meine ich, änderungen in der Struktur (Tabellen, Felder, Beziehungen).

Die Situation ist folgende:

Eine Version 1.0 einer Applikation wurde veröffentlicht. Die Weiterentwicklung dieser Applikation, hatte Veränderungen in der Datenbank zur Folge.

Die Applikation wird über eine Setup Applikation installiert, mit welcher per SQL Veränderungen an einer bereits vorhandenen Datenbank vorgenommen werden könnten. Die Applikation selbst, könnte dies beim Aufstarten beispielsweise ebenfalls erledigen. Welche Variante ist üblich?

Ebenfalls würde mich interessieren, wie das Update selbst von statten gehen soll. Ob dabei die Struktur der Datenbank analysiert wird um ausstehende Änderungen vorzunehmen, oder ob dies besser über eine in der Datenbank abgelegte Versionsnummer, welche aussagt auf welchem Stand die Datenbank bereits ist, gemacht wird.

Hinweise (Tutorials, was auch immer) nehme ich gerne entgegen.

Grüsse
hirnstroem

Ich würde:
-keine Änderungen an der Originaldatenbank durchführen, sondern in eine neue migrieren
-die Versionsnummer der Datenbank in der Datenbank ablegen

Hallo,

DB-Änderungen würde ich immer in eine eigene App auslagern.
Die startet der Admin, nachdem er den Rookies, ähem Anwendern gesagt hat,
"Jetzt mache ich nen Update".

Vorher die DB sichern (lassen).

Zu der DB-Versionsnummer (mkinzler).
Jede Änderung der DB erhöht eine Nummer in der DB selbst,
es existiert also eine Tabelle DBInfo mit Feld No (als Bsp.)

Nach erfolgreicher Aktualisierung wird die Nummer erhöht.

Dien Haupt-App kann anhand der DB-Nummer erkennen,
was alles in der DB ist und entsprechend seine SQL-Abfrage stellen,
und vor allem auch wissen, was sie nicht abfragen kann (weil es noch fehlt).


Heiko

Du Schreibst "Version 1.0 einer Applikation" und "Die Weiterentwicklung ...hatte Veränderungen in der Datenbank zur Folge".

Kann man davon aus gehen, dass die Änderungen an der Datenbank erheblich sind, sich also die Struktur der Daten geändert hat? Damit meine ich nicht, dass nur einzelne Tabellen neue Felder bekommen haben oder weitere Tabelle hinzu gekommen sind, sondern die Tabellen weiter relationalisiert (gibts das Wort ) worden sind.

Dann würde ich in einer separaten Application (DbUpdate.exe) eine neue DB anlegen und die Daten aus der alten DB entsprechend in die Neue übernehmen.

Das ganze natürlich mit Backup, Versionsnummer und Co. wie oben schon erwähnt.

Is halt ne Frage, wie groß die Änderungen an der DB sind.

EDIT

Zitat von hoika:

Dien Haupt-App kann anhand der DB-Nummer erkennen,
was alles in der DB ist und entsprechend seine SQL-Abfrage stellen,
und vor allem auch wissen, was sie nicht abfragen kann (weil es noch fehlt).

Aus Erfahrung weiß ich, dass sich das extrem bescheiden händeln lässt.

Ich schließ mich mkinzler's Meinung an. Keine Änderungen an der Originaldatenbank! Immer in eine neue migrieren!

Main,

also bei mir klappt das ganz gut.
Es ist sogar so, dass der Kunde meist selbst das DB-Update macht,
in die Original-DB im laufenden Betrieb (Firebird).

OK, OK, das klappt nur bei "Add Field", "Add Table",
grosse DB-Struktur-Änderungen vermeide ich.
Wenn es doch mal notwendig wird,
geht das nur in einem "Wartungsintervall"
oder die DB muss vom Netz.

Ich wusste ja schon vor 10 Jahren,
wie DB aufgebaut werden muss und sich entwickelt *gr*


Heiko

Ja, das meinte ich ja mit "erheblicher Änderung an der Struktur".

Für kleinere Änderungen an den Tabellen, neue Felder usw. mag deine Variante durchaus funktionieren.
Ich selbst hab das in meinen DB-Client ebenso gehandhabt. Bei einer gut überlegten DB-Struktur funktioniert das ne Zeit lang. Aber irgendwann kommt dann trotzdem der Punkt des "Wartungsintervalls". Spätest dann, wenn man führende Tabellen verändert bzw. "auseinander nimmt". Und das kann bei einem Update von Version 1.0 auf 1.x durchaus der Fall sein.

Ob man dann nun die DB vom Netz nimmt und umbaut, oder die DB in eine neue migriert muß dann jeder für sich selbst entscheiden. Kommt halt immer auf den Aufwand an, den man betreiben muß/will.

Nur nicht das Backup vergessen! Ich glaube, das ist der wichtigste Tipp den man geben kann. Denn Daten sind für viele Anwender mehr wert als Gold!

Zitat:

die Tabellen weiter relationalisiert (gibts das Wort Grübelnd... ) worden sind.

Man spricht von normalisieren

Hi,

Zitat von mkinzler:

Ich würde:
-keine Änderungen an der Originaldatenbank durchführen, sondern in eine neue migrieren

würdest Du mir bitte sagen warum du das so machst? Ich sehe hier Nachteile insbesondere wenn es sich um größere Datenmengen handelt, wegen dem Hinzufügen einer weiteren Tabelle bzw. eines weiteren Attributes zu einer Tabelle die gesamten Daten von einer DB in einer andere zu kopieren.

Dass es bei großen strukturellen Änderungen durchaus Sinn macht so vorzugehen, um nicht in die Fallen von Abhängikeiten zu tappen, (Table-Trigger-StoredProcedure) ist schon klar.

Grüße
Lemmy

'loha Folks,

vielen Dank für die rege Anteilnahme. Ich denke mit den Informationen ist mir voresrt gedient.

Die Änderungen in der Datenbank beziehen sich grösstenteils auf neue Tabellen und Felder, es gibt aber auch ein Paar wenige Felder, welche einen neuen Namen bekommen, aber bereits vorhanden und mit Daten befüllt sind.

Das Update selbst, muss fast, wie mir im Nachhinein auffiel, von der Applikation selbst durchgeführt werden, da sich mit dieser beliebig viele Datenbanken vom Kunden für weitere Kunden verwalten lassen.

Die Sicherheitskopie muss wohl - der Sicherheit wegen - sein, obwohl dies bei grösseren Datenbeständen das Update extrem verlangsamen wird, da nur wenige und kleine Änderungen vorgenommen werden. Ob dies nun wirklich nötig ist, werde ich entscheiden, wenn das Update implementiert und mit einigen Referenzdatenbanken getestet wurde. Mir ging es - mangels Erfahrung - in erster Linie darum, zu erfahren, wie ein solches Update grundsätzlich gehandhabt wird, was mir nun recht klar wurde.

Vielen Dank nochmal!

Grüsse
hirnstroem