Datenbank Tabellen Transport von Entwicklung zu Produktiv

[Lucifer21]

Hallo,

Datenbanken sind ja in ihrer Struktur ja nicht alle Fixiert.
Es gibt Zwar Programme und Datenbanken die werden einmal erstellt und erleben keine Änderung mehr.

Aber es gibt auch Programme und Datenbanken die auch zu Ihrer Laufzeit an neue Bedürfnisse Angepasst werden müssen.

Im Idealfall hat man je ein Gerät für Entwicklung, Test und Produktion.

Da es auch sein kann das mehrere Entwicklung zur gleichen Zeit stattfinden und demnach auch verschiedenstlich den Test bzw. Produktivstatus erreichen,
woher weiß man welche Tabellen, Tabellen-Spalten transportiert werden können bzw. müssen?


mfg Peter

[Christian Marquardt]

Man redet miteinander; nutzt Versionierungstools und Versionsstände

[defo]

Man redet miteinander; nutzt Versionierungstools und Versionsstände

Ich würde das noch ergänzen:
Reden ist immer gut, aber einen Plan zu haben, kann an der Stelle nicht schaden.
Versionierungstools sind m.E. unabdingbar.
Ist das System modular, gilt das um so mehr.

Hilfreich sind auch innerhalb der DB und eines Clients (Mittelschicht oder "echter" Client) Pflege von Versionsmetadaten, analog zur Versionierung des Programmcodes. Ebenso sind Code interne Prüffunktionen und auch Log- sowie Anzeige-/Abfragemöglichkeiten hilfreich.
Bspw. die Anzeige einer Programmversion (Client) ist schön, sagt aber nichts darüber aus, dass/welche DB Modell Version(en) tatsächlich im Backend vorliegen.

Je nach benötigter Flexibilität müssen stringente Konzepte für die Datenmodellpflege da sein und konsequent angewendet werden.
Das beginnt bei Alter Table Anweisungen mit passenden Defaultwerten oder sogar Datenmigrationsscripten, geht über Nutzung von Views als zusätzlichen Freiheitsgrad für Datenmodellversionierung / Interfacing und endet mit geeigneten Prüfverfahren und Abfragen während des Upgrades und des Betriebs.

Ist ein spannendes Thema, jenachdem was ein solches System leisten muss.
Der einfachste Fall (Standard) dürfte ein definiertes Verfahren mit festem Start und Endpunkt sein, bei dem vom Datenmodell bis zum geänderten Anwenderprogramm alles "hochgedreht" wird. (Inkl. geeigneter Fallbackstrategie für den Problemfall)

[Ralf Jansen]

Ergänzend, da das so klingt als wolltest du nachher rausfinden was noch an der DB zu ändern ist.
Das ist zu spät. Bei der Entwicklung eines neuen Features gehört der Upgradeprozess aller beteiligten Systeme (z.B.einer DB) natürlich dazu. Also jeder der ein neues Feature implementiert sollte auch den Upgradeprozess dazu direkt mit implementieren.
Dabei hilft dann die angesprochene Versionierung dieser Systeme.

[defo]

Ergänzend, da das so klingt als wolltest du nachher rausfinden was noch an der DB zu ändern ist.
Das ist zu spät. Bei der Entwicklung eines neuen Features gehört der Upgradeprozess aller beteiligten Systeme (z.B.einer DB) natürlich dazu. Also jeder der ein neues Feature implementiert sollte auch den Upgradeprozess dazu direkt mit implementieren.
Dabei hilft dann die angesprochene Versionierung dieser Systeme.

Das bringt es glaub ich auf den Punkt. Einiges von dem was ich geschrieben habe, dient eher dazu, den Status quo mitzuführen/festzustellen.

Und vielleicht noch eine Anmerkung:
Bspw. SAP hat dieses Verfahren im Bauch. Zwar ist es keine Datenbank, sondern eine Anwendung, am Ende ist es aber wie so oft ein Stack von Datenbank (oft Oracle), MIttelschicht, Endanwendung. Ich habe nur etwas an der Oberfläche gekratzt, daher kenne ich keine Details, aber es macht das, was Du Dir vielleicht vorstellst, angeblich vorwärts und rückwärts.

[Lucifer21]

Hallo,

Danke für die Infos.
mfg Peter

[fanderlf]

Ich glaube das Thema was Du suchst nennt sich Datenbankmigration. Such mal danach

[Lucifer21]

Hallo,

Datenbankmigration ist Wenn ich von Server A auf Server B umziehe.

aber als ganz einfaches Bsp.

Datenbank für Filme
mit zwei Tabellen
eine Tabelle mit Filme und eine für Genre
Die Datenbank steht und funktioniert alles.



Jetzt soll die Datenbank erweitert werden
für Bücher und Konsolenspiele

Es wird wahrscheinlich je eine neue Tabelle für Bücher und Konsolenspiele geben
aber auch die neuen werden auf die Tabelle Genre zugreifen.

sehr vereinfacht ausgedrückt.

mfg Peter

[defo]

Datenbankmigration ist Wenn ich von Server A auf Server B umziehe.

Ich glaube der Begriff ist nicht so exakt definiert. Ich persönlich verstehe darunter eher einen Wechsel des Datenbank Produkts und weniger den Wechsel von Server A zu B (Backup/Restore) noch das, was Du anschließend beschrieben hast (und wonach Du gefragt hast).

Deine Beschreibung ist einfach eine Datenmodelländerung und Du hast Dich nach Verfahren erkundigt, wie soetwas in Entwicklung und Produktion umgesetzt wird. In diese Richtung wurden m.E. auch die meisten Hinweise gegeben.

[Arne Drews]

Jetzt soll die Datenbank erweitert werden
für Bücher und Konsolenspiele

Es wird wahrscheinlich je eine neue Tabelle für Bücher und Konsolenspiele geben
aber auch die neuen werden auf die Tabelle Genre zugreifen.

In dem Fall macht es imho mehr Sinn, die Datenbank lediglich um eine Tabelle mit den Typen zu erweitern und nicht für jeden Typ eine neue Tabelle zu führen.
Ganz gleich, wie viele Typen/Arten noch hinzukommen, man kann diese dann grundlegend zentral verwalten.
Die Haupttabelle muss natürlich um eine Spalte "Typ" zwecks Assoziation erweitert werden.

[fanderlf]

Schau Dir mal das an https://flywaydb.org/. Das meinte ich mit Datenbankmigration. Der Begriff ist tatsächlich sehr überladen. Es geht um einen Weg Änderungen an der Struktur einer Datenbank über mehrere Instanzen derselben Datenbank vorzunehmen. Vor allem sollten diese Änderungen auch transparent sein (was ist passiert, wann ist es passiert, wer hat es veranlasst und vielleicht noch warum).