Wie lässt sich die Datenbankstruktur in einer Webanwendung auf dem neuesten Stand halten?

Question

Wenn sich Ihre Daten nach der Bereitstellung der Anwendung ändern, wie halten Sie dann die Datenbank auf dem neuesten Stand?

Ich meine, Sie können Tabellen hinzufügen oder entfernen, das ist eine einfache Aufgabe. Auch das Ändern einer bestehenden Tabelle kann trivial sein. Aber wenn Sie die Struktur häufig ändern, wie halten Sie das unter Kontrolle?

Früher habe ich eine Tabelle mit der aktuellen Datenbankversion in der Datenbank geführt. Dann war jedes Upgrade eine SQL-Datei, die ihre Arbeit machte - eine neue Tabelle erstellen, eine Spalte hinzufügen oder die Daten verschieben. Die Dateien wurden nach diesen Versionen benannt - wenn also mein Upgrade-Skript die Datenbankversion 10 erhielt, nahm es einfach alle Dateien von 11.sql bis N.sql und wendete jede einzelne davon an, wobei es die Datenbankversionsnummer gleichzeitig erhöhte.

Das scheint ganz gut zu funktionieren, aber ich frage mich, was ist Ihre Strategie für solche Aufgaben?
Außerdem scheint dieses System nicht perfekt zu sein, wenn ich eine Tabelle in einem "Patch" normalisiere und sie danach aus irgendwelchen Gründen wieder denormalisiere. Dann wird es zweimal gemacht.

Aber jedes Mal, wenn ich etwas ändere, ein komplettes Upgrade-Skript zu schreiben, scheint mühsam und fehleranfällig zu sein. Zumindest mehr als solche atomaren Änderungen.

Außerdem kann ich davon ausgehen, dass verschiedene Kunden zu jeder Zeit unterschiedliche Datenbankversionen verwenden, so dass ich wirklich eine Möglichkeit haben sollte, von jedem Punkt aus aufzusteigen.

Answer 1

Ich persönlich verwende einen sehr ähnlichen Prozess wie den, den Sie aufgelistet haben. Ich kann Ihr Argument bezüglich der Änderungen nachvollziehen, aber es kommt SEHR selten vor, dass ich eine Änderung vornehme und dann auf einer Produktionsseite wieder zur alten Methode zurückkehre. In der Testphase kommt das schon mal vor, aber im Hinblick auf eine tatsächliche Produktionssite sehe ich das nicht als große Sache an.

Die Beibehaltung einzelner Versionsskripte ist IMHO nicht nur gut für die Bereitstellung, sondern auch für die Bereitstellung von Elementen, die in die Versionskontrolle eingecheckt werden können.

Answer 2

Viele Frameworks verwenden das Konzept der "Migrationen" - Skripte, die Ihr Datenbankschema von einer Revision auf die nächsthöhere Revision aktualisieren. Auch ein Downgrade-Skript ist im Allgemeinen nützlich, falls Sie eine Änderung rückgängig machen müssen. Manchmal sind diese Skripte in SQL, manchmal sind sie abstrahiert (z. B. in Ruby on Rails). Sie können diese Skripte von Hand entwerfen oder ein Tool wie SQL Compare verwenden, das bereits von anderen erwähnt wurde.

Es ist auch hilfreich, in Ihrer Datenbank eine Tabelle mit einer Spalte und einer Zeile zu erstellen, um die Schemarevision anzugeben. Einige Frameworks, die Migrationen unterstützen, sind darauf angewiesen, um zu wissen, welche Migrationsskripte für ein Upgrade oder Downgrade des Schemas anzuwenden sind.

Ihre Anwendung sollte über eine Reihe von Tests verfügen, die Sie durchführen können, um die Funktionalität der Anwendung zu überprüfen. Sie könnten auch funktionale Tests zu dieser Suite hinzufügen, die das Schema untersuchen und bestätigen, dass die erwarteten Tabellen, Spalten, Prozeduren usw. vorhanden sind. Wenn Sie das Projekt überarbeiten, sollten Sie auch die Tests überarbeiten. Genauso wie die Tests der Anwendungsfunktionalität zusammen mit dem getesteten Code in der Versionskontrolle nachverfolgt werden müssen, müssen auch die Tests der Schemastruktur nachverfolgt werden.

Schließlich bildet der Datenbankentwurf die Grundlage für Ihren Anwendungsentwurf. Eine ordnungsgemäße Softwareentwicklung sollte zu einem relativ stabilen Datenbankschema führen, bevor Sie es einsetzen. Spätere Änderungen am Datenbankschema sollten sowohl klein als auch selten sein.

Answer 3

Zunächst haben wir eine Versionstabelle für das Schema eingeführt, die die Versionsnummer der Anwendung verfolgt, für die das Schema festgelegt ist, und wir verfolgen die Version jeder einzelnen Tabelle. Wir haben eine Schemaversion, die wir fest in die Anwendung codieren, um sie mit dieser Anwendungsversion abzugleichen. Wir wollen nicht, dass die Anwendung auf die falsche Version der DB zugreift. Wir haben dann eine Reihe von Skripten für jede Tabelle, die von der vorherigen Tabellenversion auf die aktuelle Version migriert. Wir haben dann eine Zieltabelle, die wir in die Anwendung einbetten, um zu wissen, welche Version jeder Tabelle in der neuen Version erwartet wird, um zu sehen, ob alles übereinstimmt.

kompliziert? ein wenig. lebensrettend. absolut. es gibt nichts besseres, als fehler in einer app zu suchen, weil das schema falsch ist.

Answer 4

Sie sollten sich ein Tool namens Powerdesigner ansehen. Sie können eine voll funktionsfähige 15-Tage-Testversion herunterladen. Es hilft Ihnen bei der Modellierung, hält Änderungen auf dem neuesten Stand usw.

Es ist ein großartiges Werkzeug, um das zu tun, worum Sie bitten und noch viel mehr.

Answer 5

Wir erstellen für jede Version ein Verzeichnis in unserem Versionskontroll-Repository. Wir haben ein Skript geschrieben, das die Skripte in diesem Ordner liest und sie in der Reihenfolge der Dateinamen ausführt (wir schreiben also Skripte mit Namen wie 32.0.0_AddColumnXxxxYyyy). Dieses gepunktete Format ermöglicht es uns, die Skripte nach Bedarf in die Reihenfolge einzufügen.

Wenn wir eine Website aktualisieren, werden die neuen Skripte erkannt und ausgeführt. Dies hat einen Vorteil gegenüber einem Tool wie SQL Compare (das ich sehr schätze), da wir einmalige Änderungen an den Daten vornehmen können. Wir führen jedoch SQL Compare und SQL Data Compare (für ausgewählte Tabellen) aus. après die Aktualisierung, um sicherzustellen, dass das Verfahren ordnungsgemäß funktioniert. Nach erfolgreicher Ausführung wird der gesamte Vorgang übertragen und die Datenbank aktualisiert die Informationen zu den ausgeführten Skripten, so dass diese Skripte nicht erneut ausgeführt werden.

Das Schöne an dieser Vorgehensweise ist, dass wir ein Skript nicht "vergessen" können. Außerdem finden wir beim Rollout in die Test- oder Staging-Datenbank oft versteckte Annahmen, die durch die alternativen Datensätze aufgedeckt werden, bevor sie die Produktion erreichen.

Ein weiterer Vorteil ist, dass wir verschiedene Installationen mit unterschiedlichen Funktionalitäten für verschiedene Kunden aufrechterhalten können, aber wenn wir ein Upgrade durchführen, sind alle Skripte bereits vorhanden und einsatzbereit. Das einzige Problem, das ich mit diesem Schema hatte, war die Anwendung eines Patches auf die Datenbank eines Benutzers, der "nicht in Ordnung" war... Sie müssen Ihre Skripte so schreiben, dass sie erkennen, dass der ursprüngliche Zustand wie erwartet und andernfalls abzubrechen.