Das einfach(st)e Datenbankversionierungssystem

Leider findet auch heute (im Jahre 2016!) die saubere Versionierung einer Datenbankanwendung immer noch zu wenig Beachtung. Neben Tabellen sind gespeicherte Prozeduren, Sichten oder benutzerdefinierte Typen vor allem eins: Quellcode!

Und Quellcode gehört in ein Quellcodeverwaltungssystem wie Git, Subversion oder TFS.

Achtung: in diesem Beitrag geht es um Microsoft SQL Server und entsprechend funktioniert das Tooling auch nur dafür.

Vorhandene Lösungen

Es gibt durchaus Standardlösungen zur Datenbankversionierung wie z.B. Datenbankprojekte in Visual Studio. Dort werden Änderungen nie in der Datenbank direkt durchgeführt, sondern zuerst im Datenbankprojekt, welches dann in die Datenbank deployed wird.

Bis zu einem gewissen Punkt funktioniert das nicht schlecht und wer damit klarkommt, dem soll davon nicht abgeraten werden. Dennoch gibt es immer wieder Situationen bei denen das direkte Codieren in SSMS (SQL Server Management Studio) einfacher geht – man denke nur an die Definition eines komplizierten Queries.

Außerdem gibt es noch weitere Kaufprodukte, z.B. von Apex oder Redgate. Wie gut die funktionieren und ob die ihren Preis Wert sind, soll jeder selber beurteilen.

SQL Script Generator

Für Microsoft SQL Server biete ich mit SQL Script Generator eine Konsolenanwendung, um den aktuellen Stand einer Datenbank zu dumpen. Und zwar nicht als ein einzelnes Gesamtskript, sondern nach dem Muster “je Objekt eine Datei”. Somit erhält jede Tabelle, jede Sicht und jede gespeicherte Prozedur eine separate Datei:

Dump_Structure

Wenn man diesen Dump nun regelmäßig ausführt und entsprechend versioniert, kann man im Log nun sehr schön Änderungen in der gesamten Datenbank, nur an Tabellen oder an einer bestimmten Tabelle ansehen und nachvollziehen:

ChangeLog

Im zweiten Screenshot sieht man, dass zusätzlich zu den einzelnen Dateien auch ein Script für die gesamte Datenbank (Create.sql), sowie ein weiteres Script RecreateAllNonTables.sql angelegt wird. Später mehr dazu.

Zur Generierung muss eine Profil-Datei mit der Dateiendung .sqlgen angelegt werden, wie z.B. DumpDB.sqlgen:

<?xml version="1.0" encoding="utf-8" ?>
<Profile>
 <Server>.\SQLEXPRESS12</Server>
 <DatabaseName>KnowMyUsers2.Database</DatabaseName>
 <DataTables></DataTables>
 <OutDir></OutDir>
</Profile>

Wenn SQL Script Generator installiert wurde, kann diese Datei dann im Windows Explorer einfach mit Doppelklick gestartet werden:

Executing

Jeder Entwickler muss vor dem Einchecken den Dump starten. Das war’s. So einfach kann Datenbankversionierung sein!

Weitere Einstellungsmöglichkeiten

<?xml version="1.0" encoding="utf-8" ?>
<Profile>
 <Server>.\SQLEXPRESS12</Server>
 <DatabaseName>KnowMyUsers2.Database</DatabaseName>
 <DataTables>Table1,Table2</DataTables>
 <OutDir>MainDB</OutDir>
</Profile>

Manchmal gibt es Tabellen, die statische Daten enthalten, d.h. wo die Daten Teil des Schemas sind. Diese Tabellen können unter <DataTables> als mit Komma getrennte Liste angegeben werden.

Im Tag <OutDir> kann ein relativer Pfad ausgehend von der Profildatei für das Zielverzeichnis angegeben werden.

Und das Update-Script?

Ein Update-Script wird nicht erzeugt und muss anderweitig gehandhabt werden. Ich bevorzuge dabei immer die manuelle Erstellung zur vollen Kontrolle. Durch die saubere Versionierung lassen sich die Änderungen aber prinzipiell auch einfacher Herausfinden, d.h. auf Datenbank-Diff-Tools kann man meistens auch verzichten.

Es gibt auch öfters mal das Vorgehen nur ein Update-Script zu pflegen. Dann bräuchte man natürlich das hier vorgestellte Tooling auch nicht. Meiner Ansicht nach ist die Pflege dann aber viel aufwendiger, inbesondere bei Datenbanken, die noch stark in der Entwicklung sind. Meiner Ansicht nach sollten Update-Scripte immer nur zwischen Release-Versionen erstellt werden.

Weiterhin kann man sich meiner Ansicht nach die Arbeit an Update-Skripten deutlich vereinfachen, wenn nur die Änderungen an Tabellen via Update durchgeführt werden. Alle anderen Objekte können gelöscht und wieder neu angelegt werden. Dafür kann das Skript RecreateAllNonTables.sql genutzt werden.

Wichtige Voraussetzungen

SQL Server Script Generator setzt auf Komponenten von SSMS auf, nämlich den SMO – SQL Server Management Objects. De-fakto erzeugt eine manuelle Skriptgenerierung via Management Studio die gleichen Ergebnisse – nur anders auf Dateien verteilt. Kurz: das Tool funktioniert nur, wenn SSMS installiert ist.

Download

Setup Version 1.0 + Beispiel