Datenbanken auf Vordermann bringen (Teil 2)
Kommentare

Ein zweiter Blick
Neben diesen grundlegenden Anforderungen und Einstellungen kann natürlich auch der Aufbau der Datenbank mit einer Reihe von Objekten definiert werden. Hinzugefügt werden diese Objekte

Ein zweiter Blick

Neben diesen grundlegenden Anforderungen und Einstellungen kann natürlich auch der Aufbau der Datenbank mit einer Reihe von Objekten definiert werden. Hinzugefügt werden diese Objekte über das Kontextmenü und den daraufhin erscheinenden Dialog (Abb. 6).

Abb. 6: Dialog zum Hinzufügen von weiteren Objekten in die Datenbank
Abb. 6: Dialog zum Hinzufügen von weiteren Objekten in die Datenbank

Allerdings dürfte eine mögliche Euphorie an dieser Stelle schnell ein Ende finden. Alle Objekte werden als DDL-Anweisungen notiert – eine Unterstützung in Form eines grafischen Designers sucht man bis dato vergebens. So tut man bei umfangreicheren Objekten sicherlich gut daran, diese Skripte automatisch durch das SQL Server Management Studio erstellen zu lassen. Lässt sich auf diese Weise ein Objekt nicht hinzufügen, weil dessen Typ unbekannt bzw. nicht vorgesehen ist, so bleibt nur der Weg über eigene Skripte, z. B. Script.PostDeployment.sql und Script.PostDeployment.sql, die die Aufgabe des Anlegens und Anpassens übernehmen können. Hier greift jedoch kein Automatismus mehr, die Skripte müssen selbst zwischen Installation (CREATE xxx) oder Update (ALTER xxx) unterscheiden können. Knifflig wird es nur, wenn es gilt, Abhängigkeiten zu berücksichtigen. Bei den Objekttypen, die der Datenebenenanwendung bekannt sind, geschieht das automatisch – auch partielle Änderungen, wie die an einzelnen Spalten einer Tabelle, werden automatisch durchgeführt.

Und alles wird verpackt

Sind alle Objekte vorhanden und deren Skripte so wie es benötigt wird, kann das gesamte Projekt veröffentlich werden. So wird die fertige dacpac-Datei erzeugt, die verteilt und auf einer SQL-Server-Instanz bereitgestellt, also installiert werden kann. Ein Komprimieren der Datei ist nur bedingt sinnvoll, da es sich bei der Datei, wie schon erwähnt, um ein ZIP-Archiv mit veränderter Dateierweiterung handelt. Wer möchte, kann dacpac durch zip ersetzen und einen Blick ins Innere riskieren.

Ein Paket wird ausgeliefert

Für die Bereitstellung wird, wie schon erwähnt, SQL Server Management Studio benötigt, Visual Studio selbstredend an dieser Stelle nicht (Abb. 7).

Abb. 7: Der Assistent zur Bereitstellung der Datenebenenanwendungen per SQL Server Management Studio
Abb. 7: Der Assistent zur Bereitstellung der Datenebenenanwendungen per SQL Server Management Studio

Über einen simplen Doppelklick auf die dacpac-Datei oder durch den entsprechenden Befehl im Kontextmenü wird der entsprechende Assistent gestartet. So ist sichergestellt, dass notfalls auch technisch weniger versierte Mitarbeiter die Bereitstellung erfolgreich durchführen können. Auf dem SQL Server werden zudem alle installierten Datenebenenanwendungen gespeichert, sodass automatisch erkennbar ist, ob es sich um ein Update handelt und welche Datenbank dieses betrifft. Die bereits installierten Datenebenenanwendungen sind im SQL Server Management Studio unter einem neuen Eintrag unterhalb von VERWALTUNG zu finden.

Alles hat Grenzen

Datenebenenanwendungen können leider nicht alles völlig automatisch bereitstellen, was in einer Datenbank zu finden und von Nutzen ist. Ein heikles Thema sind (wie so oft) Änderungen der Datentypen an Tabellenspalten. Beispielsweise bringt eine Änderung von VARCHAR zu BIT oder DATETIME zu INT Schwierigkeiten mit sich, die sich nicht automatisch lösen lassen. Auch ist es problematisch, eine Spalte zu löschen und gleichzeitig eine Spalte mit einem anderen Namen anzufügen. In all diesen Fällen müssen die Änderungen mittels eigenem Skript stattfinden. Das dies nicht automatisch geschieht, ist recht einleuchtend (wie sollten auch beliebige Inhalte von VARCHAR zu einem DATETIME konvertiert werden?!), richtig ärgerlich ist hier mehr, dass manche Objekttypen nicht unterstützt werden – auch wenn die große Mehrzahl an Objekttypen unterstützt werden, wie schon in dem entsprechenden Assistenten zu sehen ist. Insbesondere wird Folgendes leider nicht unterstützt:

  • Anwendungsrollen
  • Die komplette CLR-Integration (auch wenn die TRUSTWORTHY-Einstellung der Datenbank gesetzt werden kann, was allerdings für Produktionsserver eher uninteressant sein dürfte)
  • Volltextsuche
  • Filestream (BLOBs direkt in einem NTFS-Ordner abspeichern)
  • Erweiterte Eigenschaften

Anwendungen und Datenbanken, die von diesen SQL-Server-Features verstärkt Gebrauch machen, profitieren also nicht so stark von der automatischen Bereitstellung von Datenebenenanwendungen.

Fazit

Datenebenenanwendungen sind zurzeit noch in etwa so sperrig wie ihr deutscher Name, jedoch eine gute Idee, auch wenn noch massiv wichtige SQL-Server-Features und die Unterstützung durch grafische Hilfsmittel (Stichwort: Die Skripte der Objekte müssen von Hand bearbeitet werden) fehlen. Die Idee ist jedoch gut und ausbaufähig. Mein Tipp: Probieren Sie diese Methode der Bereitstellung einer SQL-Server-Datenbank einfach in einem Projekt aus, wenn der Mitarbeiter/Kunde, der diese durchführt, nicht so technisch affin ist – besser als Kilobyteweise T-SQL-Skripte laufen zu lassen, ist dieser Ansatz auch jetzt schon. Und man darf gespannt sein, was die Entwicklung an dieser Stelle bringen mag.

Thorsten Kansy ist als selbstständiger Softwarearchitekt, Entwickler und Trainer für seine internationalen Kunden tätig. Wenn es seine Zeit zulässt, schreibt er zudem Bücher und Artikel rund um „seine“ Themen, der Entwicklung komplexer Anwendungen mit .NET im Microsoft-Serverumfeld, insbesondere SQL Server. Er ist als MCSD.NET, MCSD, MCPD, MCTS, MCT, MCDBA zertifiziert und sowohl in den Sprachen C# als auch VB.NET zu Hause. Sie erreichen ihn via E-Mail.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -