Sollten sich Datenbankdateien (Skripte usw.) in der Quellcodeverwaltung befinden? Wenn ja, welche Methode eignet sich am besten, um sie dort zu speichern und zu aktualisieren?

Müssen sich Datenbankdateien überhaupt in der Quellcodeverwaltung befinden, da wir sie auf einem Entwicklungsserver ablegen können, auf dem jeder sie verwenden und bei Bedarf Änderungen daran vornehmen kann? Aber dann können wir es nicht zurückbekommen, wenn jemand es vermasselt.

Welcher Ansatz eignet sich am besten für Datenbanken zur Quellcodeverwaltung?

Ja. Sie sollten in der Lage sein, jeden Teil Ihres Systems aus der Quellcodeverwaltung einschließlich der Datenbank neu zu erstellen (und ich würde auch bestimmte statische Daten argumentieren).

Angenommen, Sie möchten kein Tool dafür haben, würde ich vorschlagen, dass Sie Folgendes einschließen:

• Erstellungsskripte für die grundlegenden Tabellenstrukturen, einschließlich Schemas, Benutzer, Tabellen, Schlüssel, Standardeinstellungen usw.
• Upgrade-Skripte (entweder die Tabellenstruktur ändern oder Daten von einem vorherigen Schema in das neue Schema migrieren)
• Erstellungsskripte für gespeicherte Prozeduren, Indizes, Ansichten und Trigger (Sie müssen sich keine Gedanken über Upgrades machen, da Sie nur die vorhandenen Skripte mit dem richtigen Erstellungsskript überschreiben.)
• Skripte zur Datenerstellung, um das System zum Laufen zu bringen (ein einzelner Benutzer, statische Auswahllistendaten usw.)

Alle Skripte sollten die entsprechenden drop-Anweisungen enthalten und so geschrieben sein, dass sie als jeder Benutzer ausgeführt werden können (einschließlich der zugehörigen Schema- / Eigentümerpräfixe, falls relevant).

Der Vorgang zum Aktualisieren / Kennzeichnen / Verzweigen sollte genau so sein wie der Rest des Quellcodes - es hat wenig Sinn, dies zu tun, wenn Sie einer Anwendungsversion keine Datenbankversion zuordnen können.

Im Übrigen hoffe ich, dass Sie den Entwicklungsserver meinen, wenn Sie sagen, dass Benutzer nur den Testserver aktualisieren können. Wenn Entwickler den Testserver im laufenden Betrieb aktualisieren, sehen Sie eine Welt voller Schmerzen, wenn es darum geht, herauszufinden, was Sie freigeben müssen.

Ja.

Was ist die beste Methode, um es dort aufzubewahren und zu aktualisieren?

Äh. Schreiben Sie ein Schema-Builder-Skript. Checken Sie es ein, nachdem Sie Änderungen vorgenommen haben. Probieren Sie es aus, bevor Sie es ausführen.

Es ist schwer zu bestimmen, wonach Sie fragen.

Schreiben Sie formale Schemamigrationsskripte. Checken Sie sie nach dem Testen ein. Überprüfen Sie sie, bevor Sie sie ausführen.

Was gibt es noch?

Was passiert ist, dass Schemaänderungen zu kniffligen Problemen werden, da sich das Schema organisch durch eine Reihe von undokumentierten Änderungen entwickelt.

Diese organische Entwicklung erschwert die Migration von Schemata, da es keine "maßgebliche" Quelle für das gibt, was dort sein soll. Es gibt zwei leicht unterschiedliche Produktionsversionen, eine Staging-Version, eine QA-Version und acht Entwicklungsversionen. Alles etwas anders.

Wenn es eine einzige autorisierende Quelle gab, ist die Schemamigration nur das Delta zwischen der letzten Version und dieser Version.

Ja

Datenbankskripte (ddl, dml) sind Code. Der gesamte Code sollte sich in einem Versionskontrollsystem befinden.

Migrationen

• Verwenden Sie Datenbankmigrationen

Ermöglicht die Verwendung derselben DB-Dateien in Entwicklung, QA und Releases.

• Mit einer Versionsnummer in die Datenbank freigeben

Bewahren Sie die Versionsnummer für Audits auf, viele speichern sie in der Datenbank. Jedes Release besteht aus Migrationen, die die Datenbank auf die richtige Version bringen.

Es gibt Tools wie liquibase, die die Quellcodeverwaltung für Datenbanken ermöglichen sollen. Es ist mühsam, Änderungs- / Aktualisierungsskripte in Ihrem regulären Versionsverwaltungstool zu verwalten, wie es viele Unternehmen tun, und Sie können die Datenbank nicht immer von Grund auf neu bereitstellen.

Wir haben auch versucht, dies mit Datenbankvergleichstools zu automatisieren (Vergleich von Master- und Kundendatenbank), und das hat geholfen, aber Sie können solchen Tools nicht zu 100% vertrauen. Sie benötigen auf jeden Fall auch einen Überprüfungsprozess.

Ja

Und außerdem willst du Zweige .

Ich benutze Git für Äste:

• für die Entwicklung pro Feature (wie für die reguläre Entwicklung der restlichen Anwendung)

• und eine für den Produktionsserver, da Kunden, die die Anwendung verwenden, auch Inhalte erstellen.

Auf diese Weise erhalten Sie die Vorteile der Quellcodeverwaltung und -verzweigung sowohl für Quellcodes als auch für Datenbanken (und alle anderen Dateien, die Sie haben).

Ich habe noch kein All-in-One-System gefunden [für PostgreSQL], daher musste ich Funktionen / Skripte schreiben, um die Zusammenführung von Zweigen ordnungsgemäß zu indizieren Indizes + Fremdschlüssel aus dem Entwicklungszweig, die sich mit Produktionsinhalten überschneiden, sollten neu indiziert werden: Es würde nicht für alle Anwendungen funktionieren, aber es deckt alle Fälle unserer Anwendung ab, also ist es gut genug.

Die allgemeine Idee ist jedoch, dass Datenbankinhalte ein wesentlicher Bestandteil der Anwendung sind und alle Ressourcen in der Quellcodeverwaltung sein sollten. Daher sollten Sie die Quellcodeverwaltung auch für die Datenbank verwenden.

Für Java verwendet unser Team Flyway , das für uns sehr einfach zu bedienen und leistungsstark ist.

Wenn Sie in Ruby arbeiten, verfügt Rails über Migrationen, die auch eine leistungsstarke Methode zur Behebung dieses Problems darstellen.

Liquibase wurde bereits erwähnt - es ist eine gute Lösung, aber ich fand es umständlicher als Alternativen wie Flyway.

Die RedGate-Software bietet auch ein Produkt namens SQL Source Control an , das für SQL Server entwickelt wurde. Ich habe es selbst nicht benutzt, aber einer meiner Kollegen sagt, es sei großartig.

Hier ist das Problem, das ich oft gesehen habe, wenn es keine Versionskontrolle oder Änderungsverwaltung für Entwicklungsdatenbanken gibt. Programmierer A nimmt eine Änderung an einer Tabelle, einer Ansicht oder einem Prozess vor. Programmierer B ändert dasselbe und überschreibt, was Programmierer A getan hat. Oder DBA stellt eine Produktionsdatenbank für die Entwicklung wieder her und überschreibt Änderungen. Ich habe gesehen, dass solche Sachen so oft großen Kummer verursachen, dass sie nicht lustig sind. Und das nur auf Entwicklungssystemen. Beim Staging / Testen kann es sehr unübersichtlich werden, und selbst Produktionsserver sind hiervon betroffen.

Die Versionskontrolle der Datenbank muss nicht mit der regulären Codeversionskontrolle identisch sein, um wirksam zu sein. Eine Art Änderungskontrolle und Verlaufssicherungen verhindern jedoch viele Probleme.

Stellen Sie es sich als "Versionskontrolle" und nicht als "Quellcodeverwaltung" vor. Dies bedeutet, dass Sie den gesamten Verlauf dieses bestimmten Skripts anzeigen können. Ob Sie die Datenbank auf das aktuelle Formular zurücksetzen können oder nicht, hängt mehr von Ihren Vorgehensweisen in Bezug auf diese Skripts und die für deren Erstellung verwendeten Frameworks ab.

Für unsere PHP / MySQL-Projekte haben wir ein (einmaliges) kleines Tool namens Ladder verwendet . Es wurde entwickelt, um das organische Wachstum einer Datenbank im Laufe der Zeit zu erleichtern. Alle Migrationen für ein Projekt werden in der Revisions- / Quell- / Versionskontrolle gespeichert und zusammen mit dem Code verfolgt.

Es unterstützt das Hinzufügen / Ändern / Löschen von Spalten, das Ausführen von Abfragen, das Hinzufügen / Löschen von Indizes, Einschränkungen usw. Es verfolgt den Status der Datenbank und wendet fehlende Migrationen an. Außerdem können Sie die Zeit zurückversetzen, indem Sie eine Migration angeben, bei der Sie sich befinden müssen. ( php ladder.php migrate 15)

Oh, und die neueste Ergänzung ist Datenbankunterschiede. Führen Sie den diff-saveBefehl aus, fügen Sie einige Spalten hinzu, entfernen Sie sie aus der Datenbank, und führen Sie den diffBefehl aus. Sie sehen automatisch generierten Migrationscode basierend auf dem Datenbankstatus.

DataGrove löst einige der hier genannten Probleme ( z. B. von jfrankcarr ).

Es verfolgt alle Änderungen an einer DB und ermöglicht Ihnen, eine Version des gesamten DB-Status in einem Repository zu speichern. Anschließend können Sie mehrere virtuelle Kopien derselben Datenbank erzeugen, sodass jeder Entwickler oder DBA eine eigene Kopie haben kann (jede virtuelle Kopie kann aus einer anderen Version erzeugt werden). Es stellt sicher, dass niemand den Code / die Änderungen anderer überschreibt. Jede der virtuellen Kopien wird auch in denselben Repositorys nachverfolgt, sodass alle DB-Status einfach gemeinsam genutzt und neu erstellt werden können.

Ich möchte auch ein Überwachungstool mitbringen, das auch als Datenversionierungstool verwendet werden kann. Das Tool, über das ich spreche, ist MONyog, eigentlich ist es ein MySQL-Überwachungstool, aber mit ein wenig Hack können wir es leicht als Datenversionierung verwenden.

Bevor ich jedoch fortfahre, zitiere ich, dass es nicht ratsam ist, die gesamte Datenbank für die Versionierung einzurichten. Es ist ein echter Mörder, Änderungen für einen bestimmten Datensatz zu verfolgen.

MONyog verfügt über eine Funktion namens CSO (Custom SQL Objects), die die Änderung bestimmter Datenmengen überwachen kann. Das Hinzufügen eines CSO wird hier beschrieben . Jetzt können Sie im MONyog-Monitorverlauf die Änderungen über einen bestimmten Zeitraum abrufen. Am besten gibt es einen visuellen Bericht in HTML-Seite. Der Bericht wird ungefähr so ​​aussehen