Wie führt man Versionskontrolle für eine SQL Server-Datenbank durch?

Question

Ich möchte meine Datenbanken unter Versionskontrolle halten.

Ich möchte immer zumindest einige Daten darin haben (wie alumb erwähnt: Benutzertypen und Administratoren). Oft möchte ich auch eine große Sammlung generierter Testdaten für Leistungsmessungen haben.

Wie kann ich Versionskontrolle auf meine Datenbank anwenden?

Answer 1

Martin Fowler schrieb meinen Lieblingsartikel zum Thema, http://martinfowler.com/articles/evodb.html. Ich entscheide mich dagegen, Schema-Dumps unter Versionskontrolle zu stellen, wie es alumb und andere vorschlagen, weil ich einen einfachen Weg möchte, um meine Produktionsdatenbank zu aktualisieren.

Für eine Webanwendung, bei der ich eine einzelne Produktionsdatenbankinstanz haben werde, verwende ich zwei Techniken:

Datenbank-Upgrade-Skripte

Eine Sequenz von Datenbank-Upgrade-Skripten, die das DDL enthalten, das erforderlich ist, um das Schema von Version N auf N+1 zu verschieben. (Diese werden in Ihrem Versionskontrollsystem abgelegt.) Eine _version_history_ Tabelle, etwas wie

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

erhält jedes Mal einen neuen Eintrag, wenn ein Upgrade-Skript ausgeführt wird, das der neuen Version entspricht.

Dies stellt sicher, dass es einfach ist zu erkennen, welche Version des Datenbankschemas existiert und dass Datenbank-Upgrade-Skripte nur einmal ausgeführt werden. Nochmals, dies sind keine Datenbankdumps. Vielmehr repräsentiert jedes Skript die Änderungen, die erforderlich sind, um von einer Version zur nächsten zu gelangen. Es sind die Skripte, die Sie auf Ihre Produktionsdatenbank anwenden, um sie zu "aktualisieren".

Entwickler-Sandbox-Synchronisierung

1. Ein Skript zum Sichern, Säubern und Verkleinern einer Produktionsdatenbank. Führen Sie dies nach jedem Upgrade in die Produktions-DB aus.
2. Ein Skript zum Wiederherstellen (und Anpassen, falls erforderlich) des Backups auf dem Entwicklungsrechner. Jeder Entwickler führt dieses Skript nach jedem Upgrade auf die Produktionsdatenbank aus.

Eine Einschränkung: Meine automatisierten Tests laufen gegen eine schema-korrekte, aber leere Datenbank, sodass dieser Ratschlag nicht perfekt für Ihre Anforderungen geeignet ist.

Answer 2

Es gibt mehrere kommerzielle Produkte, die diese Funktionalität bieten:

• RedGate SQL Source Control
• VersionSQL
• ApexSQL

Für RedGate-Benutzer

Wenn Sie das Produkt SQL Compare von Red Gate verwenden - können Sie Objektvergleiche auf Ebene des Objekts durchführen und Änderungsskripte generieren. Es ermöglicht Ihnen auch, Ihre Datenbankobjekte in eine Verzeichnishierarchie zu exportieren, die nach Objekttyp organisiert ist, mit einem [Objektname].sql-Erstellungsskript pro Objekt in diesen Verzeichnissen. Die Objekttyp-Hierarchie sieht wie folgt aus:

\Funktionen
\Sicherheit
\Sicherheit\Rollen
\Sicherheit\Schemas
\Sicherheit\Benutzer
\Gespeicherte Prozeduren
\Tabellen

Wenn Sie Ihre Skripte in dasselbe Stammverzeichnis ablegen, nachdem Sie Änderungen vorgenommen haben, können Sie dies nutzen, um Ihr SVN-Repository zu aktualisieren und eine fortlaufende Historie von jedem Objekt einzeln zu führen.

Answer 3

Zuerst müssen Sie das Versionskontrollsystem auswählen, das zu Ihnen passt:

• Zentralisiertes Versionskontrollsystem - ein Standard-System, bei dem Benutzer Dateien ein- und auschecken, bevor/sie daran arbeiten, und die Dateien werden auf einem einzigen zentralen Server aufbewahrt

• Verteiltes Versionskontrollsystem - ein System, bei dem das Repository geklont wird und jeder Klon tatsächlich das vollständige Backup des Repositorys ist, sodass im Falle eines Serverabsturzes jedes geklonte Repository zur Wiederherstellung verwendet werden kann. Nachdem Sie das richtige System für Ihre Bedürfnisse ausgewählt haben, müssen Sie das Repository einrichten, das der Kern jedes Versionskontrollsystems ist. All dies wird im folgenden Artikel erklärt: http://solutioncenter.apexsql.com/sql-server-source-control-part-i-understanding-source-control-basics/

Nachdem Sie ein Repository eingerichtet haben und bei einem zentralen Versionskontrollsystem einen Arbeitsordner haben, können Sie diesen Artikel lesen. Er zeigt, wie Sie die Quellcodeverwaltung in einer Entwicklungsumgebung einrichten können, unter Verwendung von:

• SQL Server Management Studio über den MSSCCI-Provider,

• Visual Studio und SQL Server Data Tools

• Ein 3rd-Party-Tool ApexSQL Source Control

Answer 4

Dies ist eines der "schwierigen Probleme" im Bereich der Entwicklung. Soweit ich weiß, gibt es keine perfekten Lösungen.

Wenn Sie nur die Datenbankstruktur speichern müssen und nicht die Daten, können Sie die Datenbank als SQL-Abfragen exportieren. (Im Enterprise Manager: Rechtsklick auf Datenbank -> SQL-Skript generieren. Ich empfehle, das Kästchen "eine Datei pro Objekt erstellen" im Reiter "Optionen" zu setzen). Diese Textdateien können dann in SVN eingecheckt werden und von den Diff- und Logging-Funktionen von SVN profitieren.

Ich habe dies mit einem Batch-Skript verbunden, das ein paar Parameter annimmt und die Datenbank einrichtet. Außerdem habe ich zusätzliche Abfragen hinzugefügt, die standardmäßige Daten wie Benutzertypen und den Admin-Benutzer eingeben. (Wenn Sie mehr Informationen dazu möchten, posten Sie etwas und ich kann das Skript irgendwo zugänglich machen)

Wenn Sie alle Daten behalten müssen, empfehle ich, ein Backup der Datenbank zu erstellen und Redgate-Produkte (http://www.red-gate.com/) für die Vergleiche zu verwenden. Sie sind nicht billig, aber jeden Cent wert.

Answer 5

Hier bei Red Gate bieten wir ein Tool, SQL Source Control, das die SQL Compare-Technologie verwendet, um Ihre Datenbank mit einem TFS- oder SVN-Repository zu verbinden. Dieses Tool integriert sich in SSMS und ermöglicht es Ihnen, wie gewohnt zu arbeiten, außer dass Sie jetzt die Objekte übergeben können.

Für einen migrationsbasierten Ansatz (der für automatisierte Bereitstellungen besser geeignet ist), bieten wir SQL Change Automation (früher ReadyRoll genannt) an, das eine Reihe inkrementeller Skripte als Visual Studio-Projekt erstellt und verwaltet.

In SQL Source Control ist es möglich, statische Datentabellen anzugeben. Diese werden im Quellcode als INSERT-Anweisungen gespeichert.

Wenn es um Testdaten geht, empfehlen wir entweder, Testdaten mit einem Tool zu generieren oder über ein von Ihnen definiertes Post-Deployment-Skript zu definieren, oder Sie stellen einfach ein Produktions-Backup in der Entwicklerumgebung wieder her.