in einer Webanwendung, wie halten Sie die Datenbankstruktur auf dem neuesten Stand?

Question

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

Ich meine, Sie können Tabelle hinzufügen oder entfernen, das ist eine einfache Aufgabe. Das Ändern einer vorhandenen Tabelle kann ebenfalls trivial sein. Aber wenn Sie die Struktur oft ändern, wie behalten Sie das unter Kontrolle?

Ich habe eine Tabelle mit einer aktuellen Datenbankversion in der Datenbank behalten. Dann war jede Aktualisierung eine SQL-Datei, die ihre Arbeit verrichtet hat - 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 hatte, wurden nur alle Dateien von 11.sql nach N.sql übernommen und jeder von ihnen gleichzeitig die Versionsnummer der Datenbank inkrementiert.

Das scheint zu funktionieren, aber ich frage mich - was ist Ihre Strategie für solche Aufgaben?
Auch dieses System scheint nicht perfekt, wenn ich eine Tabelle in einem "Patch" normalisieren und danach aus irgendwelchen Gründen wieder denormalisieren. Dann ist es zweimal getan.

Aber jedes Mal, wenn ich etwas ändere, schreibe ich ein komplettes Upgrade-Skript, das schmerzhaft und fehleranfällig ist. Zumindest mehr als solche atomaren Veränderungen.

Auch kann ich erwarten, dass verschiedene Kunden verschiedene Datenbankversionen zu jeder Zeit ausgeführt haben, so dass ich wirklich einen Weg haben sollte, von jedem Punkt zu gehen.

Answer 1

Persönlich verwende ich einen sehr ähnlichen Prozess zu dem, was Sie aufgeführt haben, kann ich Ihre Argumentation über Änderungen sehen, aber sehr selten mache ich eine Änderung, dann ändern Sie es wieder auf die alte Art und Weise auf einer Produktionsstätte. In Tests, ja, das passiert, aber in Bezug auf eine tatsächliche Produktionsstätte sehe ich es nicht als eine große Sache.

Mit einzelnen Versionsskripten ist IMHO nicht nur für die Bereitstellung geeignet, sondern auch für die Bereitstellung von Elementen, die in die Quellcodeverwaltung eingecheckt werden können.

Answer 2

Verwenden Sie ein Tool wie RedGate SQLCompare oder xSQL-Objekt von xSQL-Software, um Ihre diff/Delta T-SQL-Skripte im laufenden Betrieb zu generieren.

Sie können es sogar als Teil Ihres Build-Prozesses integrieren, wenn Sie möchten.

Für verschiedene Kunden mit verschiedenen Datenbanken haben Sie einfach verschiedene Referenzdatenbanken für die Sie vergleichen können. Sobald Sie ein Update für einen Kunden freigeben, aktualisieren Sie Ihre eigene Referenzseite mit demselben diff-Skript.

Das ist es in aller Kürze.

Answer 3

Sie sollten in ein Tool namens Powerdesigner schauen. Sie können eine 15-tägige Testversion herunterladen. Es wird Ihnen helfen, zu modellieren, Änderungen auf dem neuesten Stand zu halten usw.

Es ist ein großartiges Werkzeug, um zu tun, was Sie verlangen und noch viel mehr.

Answer 4

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

Wenn wir eine Site aktualisieren, werden die neuen Scripts erkannt und ausgeführt. Dies hat einen Vorteil gegenüber einem Tool wie SQL Compare (das ich sehr liebe), da wir einmal Änderungen an Daten vornehmen können.Wir führen jedoch SQL Compare und SQL Data Compare (in ausgewählten Tabellen) nach das Update, um sicherzustellen, dass die Prozedur ordnungsgemäß funktionierte. Nach einer erfolgreichen Ausführung wird die gesamte Operation festgeschrieben und die Datenbank aktualisiert die Informationen zum Ausführen von Skripts, damit diese Skripts nicht erneut ausgeführt werden.

Das Schöne daran ist, dass wir ein Skript nicht "vergessen" können. Wenn wir versuchen, zu der Test- oder Staging-Datenbank zu rollen, finden wir häufig versteckte Annahmen, die die alternativen Datensätze vor der Produktion aufspüren.

Ein weiterer Vorteil besteht darin, dass wir verschiedene Installationen auf verschiedenen Funktionalitätsstufen für verschiedene Kunden beibehalten können. Wenn wir jedoch ein Upgrade durchführen, sind alle Skripts vorhanden und können sofort ausgeführt werden. Das einzige Problem, das ich mit diesem Schema hatte, ist ein "out of order" -Patch, der auf die Datenbank eines Benutzers angewendet wird ... Sie müssen Ihre Skripts schreiben, um zu erkennen, dass der ursprüngliche Zustand wie erwartet ist und abzubrechen, wenn nicht.

Answer 5

Viele Frameworks verwenden das Konzept der "Migrationen" - Scripts, die Ihr Datenbankschema von einer Revision auf die nächsthöhere aktualisieren. Ebenso ist das Downgrade-Skript in der Regel hilfreich, falls Sie eine Änderung rückgängig machen müssen. Manchmal sind diese Skripte in SQL, manchmal sind sie abstrahiert (z. B. Ruby on Rails). Sie können diese Skripts manuell erstellen oder ein Tool wie SQL Compare verwenden, das andere bereits erwähnt haben.

Es ist auch hilfreich, eine Tabelle in Ihrer Datenbank mit einer Spalte, einer Zeile zu erstellen, um die Schemaversion anzuzeigen. Einige Frameworks, die Migrationen unterstützen, müssen davon wissen, welche Migrationsskripte für das Upgrade oder Downgrade des Schemas gelten.

Ihre Anwendung sollte über eine Reihe von Tests verfügen, die Sie ausführen können, um die Anwendungsfunktionalität zu überprüfen. Sie könnten dieser Suite auch Funktionstests hinzufügen, die das Schema prüfen und bestätigen, dass die erwarteten Tabellen, Spalten, Prozeduren usw. vorhanden sind. Während Sie das Projekt überarbeiten, überarbeiten Sie die Tests. Genau wie Tests der Anwendungsfunktionalität in der Quellcodeverwaltung zusammen mit dem von ihnen getesteten Code verfolgt werden müssen, müssen auch Tests der Schemastruktur verfolgt werden.

Schließlich bildet das Datenbankdesign die Grundlage für Ihr Anwendungsdesign. Die richtige Softwareentwicklung sollte vor der Bereitstellung zu einem relativ stabilen Datenbankschema führen. Nachfolgende Änderungen am Datenbankschema sollten sowohl klein als auch selten sein.

Answer 6

Ich mache es auf die gleiche Weise wie Sie. Ich behalte eine Datenbank-Release-Notes-Datei, die alle Änderungen mit meiner neuesten an der Spitze mit der Subversion Revisionsnummer aufgeführt hat. Es enthält außerdem das SQL, das ausgeführt wurde, um diese Änderung zu übernehmen.

Parallel pflege ich ein Datenbankmodell (ich benutze Azzurri Clay in Eclipse), so dass ich mein Modell jederzeit neu generieren kann. Alle Änderungen, die ich vornehmen muss, mache ich zuerst im Modell und aktualisiere dann meine Release Notes. Azzurri kann keine ALTERationen generieren, sondern nur CREATEs.

Dies ist alles unter Subversion gespeichert, so dass ich bei Bedarf zurückrollen kann. Ich sollte wahrscheinlich eine Art Verbindung zwischen der SVN-Revision meiner App und der Überarbeitung meines Modells behalten.

Answer 7

Zuerst haben wir eine Versionstabelle eingeführt, die das Schema der Versionsnummer der Anwendung enthält, für die das Schema festgelegt ist, und wir verfolgen die Version jeder einzelnen Tabelle. Wir haben eine Schemaversion, die wir hart in die Anwendung einprogrammieren, um sie mit dieser Anwendungsversion zu vergleichen. Wir möchten nicht, dass die Anwendung auf die falsche Version der Datenbank 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 wir alle übereinstimmen.Ist dies nicht der Fall, wenden wir die verschiedenen Migrationsskripte auf das Schema an, um die db auf "snuff" zu bringen.

kompliziert? etwas. lebensrettend. absolut. nichts wie Verfolgen von Fehlern in einer App, weil das Schema falsch ist.

Answer 8

Sie wahrscheinlich eine Weile Schrecken zurück auf die Codierung der Aticle, die Atwood schrieb am DB Versionskontrolle sollte lauten: Is Your Database Under Version Control?