SQL Server Development Tools

Das "Juneau"-Datenbankprojekt

Jamie Laflen

Barlay Hill

SQL Server Developer Tools oder SSDT (Codename "Juneau") zeigt das fortlaufende Engagement von Microsoft für die Bereitstellung integrierter Tools für Entwickler, die für Microsoft SQL Server entwickeln. Entwickler, die mit den früheren Versionen des Datenbankprojekts in Visual Studio vertraut sind, werden feststellen, dass es sich bei Juneau um eine Weiterentwicklung der Tools für SQL Server handelt. Zusätzlich gibt es neue Funktionen sowie Verbesserungen. Juneau stellt einen einheitlichen Satz von Tools bereit, der die Projekte aus SQL Server Business Intelligence Design Studio (BIDS), darunter Reporting-, Analysis- und Integration Services-Projekte, mit dem SQL Server Database Project verbindet.

Sie können Juneau als unabhängige Lösung installieren. Ihnen stehen auch in diesem Fall alle Funktionen bereit, die Sie für die Entwicklung von Datenbanken für SQL Server benötigen. Juneau ist jedoch auch in Visual Studio integriert, sodass Sie Ihre Datenbanken in der gleichen Umgebung wie Ihre Anwendungen entwickeln können. Juneau ist im Rahmen von SQL Server 2011 (Codename "Denali") verfügbar, wird jedoch auch in zukünftigen Versionen von Visual Studio enthalten sein.

In diesem Artikel wird das "Juneau"-Datenbankprojekt behandelt. Dieses Projektsystem und dessen Funktionen stellen die Tools bereit, die für das Bearbeiten, Kompilieren und Umgestalten von Datenbanken sowie deren Veröffentlichung als bestimmte Versionen von SQL Server und SQL Azure erforderlich sind. In Juneau gibt es für alle Versionen von SQL Server ein einziges Datenbankprojekt das sowohl Transact-SQL-Skripts (T-SQL-Skripts) als auch Code enthalten kann, der SQL CLR-Objekte definiert. Betrachten wir zunächst die Einrichtung eines Datenbankprojekts.

Das Datenbankprojekt

Das Datenbankprojekt ist ein Visual Studio-Projekt, das die Offlineentwicklung von SQL Server-Datenbanken ermöglicht. Ein Datenbankentwicklungsteam wechselt zur projektbasierten Entwicklung, um die Vorteile zu nutzen, die diese Art von Entwicklung im Vergleich zur Entwicklung mit freigegebenen Livedatenbanken hat, darunter:

• Isolierung von Änderungen von Entwicklern
• Umfangreiche Unterstützung für die Bearbeitung von T-SQL
• Verifizierung der Quelle vor der Bereitstellung und Durchsetzung von Kodierungsstandards im Team anhand von Regeln für die Codeanalyse
• Automatisierte Generierung von Migrierungsskripten

Das Projektsystem ist im Kern seinem Vorgänger Visual Studio Database Project (.dbproj) sehr ähnlich, in dem Entwickler Objekte deklarativ als CREATE-Anweisungen ausgedrückt haben. Weitere Hintergrundinformationen zur Offlineentwicklung von Schemen finden Sie unter bit.ly/raDMNx.

Einrichten eines Projekts

Wenn Sie ein Datenbankprojekt erstellen, wird es als leer angezeigt, wie die meisten anderen, mit Visual Studio erstellten Projekte. Das bedeutet, dass Sie Quellcode hinzufügen und anschließend entwickeln und debuggen können, bevor Sie diesen der Quellcodeverwaltung hinzufügen. Anders als bei den meisten anderen Projekten, in denen Sie mit dem Quellcode beginnen müssen, kann ein Datenbankprojekt aus einer vorhandenen SQL Server-Datenbank erstellt werden. Es gibt verschiedene Möglichkeiten, ein Projekt mit Quellcode zu füllen, abhängig davon, wie viel Kontrolle Sie behalten möchten:

• Importieren einer vollständigen Datenbank
• Importieren von Skripten
• Importieren eines Datenbankpakets (.dacpac)
• Schreiben von Updates für spezifische Projekte aufgrund des Vergleichs eines Projekts mit einer Datenbank
• Drag-and-Drop aus Server Explorer
• Konvertieren eines vorhandenen Visual Studio 2010-Projekts (Datenbank/SQL CLR) in ein SQL Server-Datenbankprojekt

Das von Ihnen erstellte Projekt modelliert eine Datenbank. Die Datenbankeigenschaften (z. B. Sortierung) werden in den Eigenschaften des Projekts gespeichert. Die Benutzerobjekte werden im Projekt als Quelle gespeichert. Das Datenbankprojekt ist die Offlinedarstellung Ihrer Datenbank im Quellcodeformat.

Zur Einführung beginnen wir mit einem neuen, leeren Datenbankprojekt und zeigen Ihnen die einzelnen Funktionen. Es gibt mehrere Möglichkeiten, ein Datenbankprojekt zu erstellen. Da wir mit einem leeren Projekt beginnen, müssen Sie nur auf "Datei | Neu | Projekt" klicken und anschließend das SQL Server-Datenbankprojekt auswählen, wie in Abbildung 1 gezeigt.

Abbildung 1 Erstellen eines neuen SQL Server-Datenbankprojekts

Hinzufügen von Quellen zu Ihrem Projekt

Die meisten Datenbanken enthalten mindestens eine Tabelle. Wir fügen daher nun eine Tabelle hinzu. SQL Server Database Project stellt für viele der häufig verwendeten SQL-Objekte vordefinierte T-SQL-Vorlagen bereit. Um ein neues Objekt zu erstellen, klicken Sie mit der rechten Maustaste auf den Projektknoten und wählen "Hinzufügen | Tabelle" aus. Anschließend geben Sie im Dialogfeld den Namen ein. Wir nennen das Objekt "Kunde".

Abbildung 2 zeigt, wie eine neue Tabelle im Designer für neue Tabellen aussieht.

Abbildung 2 Der Designer für neue Tabellen

Wie im Fall des HTML-Designers ist das Fenster für den Tabellen-Designer per Voreinstellung in zwei Bereiche aufgeteilt. Das Fenster für den Designer enthält eine grafische Darstellung der Tabelle sowie die Skriptdefinition der Tabelle. Unabhängig von der Ansicht, in der Sie arbeiten, werden Ihre Änderungen mit der jeweils anderen Ansicht synchronisiert.

Häufig ist der direkte Zugriff auf eine Tabelle eingeschränkt, und Sie müssen eine gespeicherte Prozedur schreiben, um einer Anwendung programmatischen Zugriff auf die Daten der Tabelle zu geben. Daher fügen wir auf die gleiche Art, wie wir die Tabelle "Kunde" hinzugefügt haben, eine gespeicherte Prozedur namens "CreateCustomer" hinzu. Der Editor wird geöffnet, und Ihnen wird ein vordefiniertes Gerüst für eine Prozedur angezeigt, das Sie ausfüllen können. Dies erscheint Ihnen möglicherweise als etwas schwierig, da viele Entwickler die gespeicherten Prozeduren anhand einer Livedatenbank entwickeln, sodass sie ihren Code während der Erstellung ausführen und validieren können. Machen Sie sich keine Sorgen. Das Datenbankprojekt erstellt eine neue Datenbank zum Debuggen, sodass die projektbasierte Entwicklung sehr viel produktiver wird. Sie können im Editor Text auswählen und mit der rechten Maustaste auf diesen klicken, um das Kontextmenü anzuzeigen, wie in Abbildung 3 gezeigt.

Abbildung 3 Ausführen von Projektquellcode anhand der Datenbank zum Debuggen

Wie funktioniert das Ausführen des Texts mittels "Abfrage ausführen", ohne dass Sie eine Verbindungszeichenfolge konfiguriert haben? Beim Öffnen des Quellcodes wird der Editor für die Ausführung anhand der Datenbank zum Debuggen konfiguriert, wenn er zur Ausführung des Skripts oder des ausgewählten Texts aufgefordert wird. Zusätzlich wird die Datenbank zum Debuggen aktualisiert, wenn Sie mit dem Debuggen beginnen (indem Sie z. B. die Taste F5 oder die Tasten Strg+F5 drücken), um der Quelle des Datenbankprojekts zu entsprechen. Juneau nutzt eine neue Funktion in Denali namens SQL Server Express LocalDB, um automatisch eine Instanz und Datenbanken zu erstellen, anhand derer Sie entwickeln und debuggen können. Weitere Informationen finden Sie unten im Abschnitt "Einführung in SQL Server Express LocalDB".

Entwickeln Ihrer Quelle

Nachdem Sie LocalDB gesehen und erfahren haben, wie Sie in Ihrem Quellcode gespeicherte Prozeduren entwickeln können, sollten Sie sich über die anderen hervorragenden Funktionen im Datenbankprojekt informieren. Das sehr nützliche IntelliSense im Projektsystem wurde auf der Basis von Feedback zu SQL Server Management Studio (SSMS) und Database Project verbessert. Viele Änderungen stellen lediglich Feinanpassungen dar, einige sind jedoch wichtig:

• Vorschaumodus: Eines der größten Probleme von T-SQL IntelliSense stellte die nicht beabsichtige Vervollständigung dar, wenn auf noch zu definierende Typen verwiesen wurde. Beispielsweise wollten Sie Folgendes eingeben: 

    select t.id from Table1 as t

Die Eingabe eines Punktes im Anschluss an

    select t

hätte jedoch zum folgenden Ergebnis geführt:

    select Table1.

Dieses Problem wurde durch das Hinzufügen eines Vorschaumodus in IntelliSense behoben. Im Vorschaumodus können Benutzer eine Reihe von Vervollständigungen anzeigen. Die Vervollständigung wird jedoch nicht automatisch durchgeführt, wenn sie die Vervollständigung nicht aktivieren (mittels der Pfeile nach unten oder oben).

• IntelliSense mit nicht gespeicherten Dateien: In früheren Datenbankprojekten mussten Sie eine Datei speichern, um die in dieser Datei definierten Objekte für IntelliSense zur Verfügung zu stellen. Beispielsweise wurde früher eine neu hinzugefügte Datei nicht in IntelliSense angezeigt, bis die Datei der Tabelle gespeichert wurde. Nun wird die Tabelle in IntelliSense angezeigt, auch wenn die Datei nicht gespeichert wurde.

Bei der Planung von Juneau hatte das Team das Ziel, die T-SQL-Entwicklungsumgebung dem Niveau der Umgebungen anderer verwalteter Sprachen anzupassen. Daher wurde der Editor innerhalb des Projektsystems optimiert, um häufig verwendete Sprachfunktionen wie die GOTO-Definition bereitzustellen, sämtliche Verweise anzeigen zu können und die direkte Umgestaltung aus dem Editor heraus zu ermöglichen, wenn auf eine Objektdefinition oder einen Verweis geklickt wird.

Wie Sie wissen, ist die Umgestaltung einer Datenbank sehr viel schwieriger als die Umgestaltung von Anwendungscode, da Datenbanken Daten enthalten. Ein anscheinend harmloser Name kann aufgrund der Abhängigkeiten von anderen Objekten zu zahlreichen zusätzlichen Änderungen führen. Außerdem können Datenverluste die Folge sein, wenn diese Änderungen implementiert werden, was sehr viel schlimmer ist. Juneau überwacht die Umgestaltungsprozesse im Projekt, indem die Änderungen in MsdnDemo.refactorlog (in unserem Fall) überwacht werden, sodass diese Prozesse berücksichtigt und die entsprechenden sp_rename- oder ALTER SCHEMA-Anweisungen generiert werden können.

In anderen verwalteten Sprachen stellt das Erstellen des Projekts den letzten Schritt vor der Ausführung des neuen Codes dar. Bei der Datenbankentwicklung wäre dies die Erstellung aller Datenbankobjekte im Projekt innerhalb einer ausgeführten Instanz. Um eine Datenbank in einem Datenbankprojekt vollständig verifizieren zu können, nutzt Juneau eine weitere neue Funktion in SQL Server Denali namens SQL Server T-SQL Compiler Services. Diese Komponente ermöglicht die vollständige Verifizierung Ihres Quellcodes, ohne dass diese Quelle mittels eines SQL Server-Servers, der live ist, ausgeführt werden muss. Fügen Sie hierfür im Anschluss an die Prozedur "CreateCustomer" den folgenden Code ein:

    go
    
    create table dbo.ExtendedVerificationDemo
    
    (
    
      c1 int null,
    
      c2 as c2 + 5
    
    )

Nach der Erstellung des Projekts wird Ihnen der folgende Fehler in der Fehlerliste und im Ausgabefenster angezeigt:

E:\projects\MsdnDemo\MsdnDemo\CreateCustomer.sql(12,1): Error:  SQL01759: Computed column 'c2' in table 'ExtendedVerificationDemo' is not allowed to be used in another computed-column definition.

Wie Sie sehen, entspricht diese Fehlermeldung genau dem, was auch das SQL Server-Modul melden würde. In diesem Fall besagt die Meldung, dass eine berechnete Spalte nicht auf sich selbst verweisen darf. Diese Funktion ist zwar sehr nützlich, Sie müssen sie jedoch in einigen Fällen deaktivieren, z. B. in diesem Fall:

• Das Verifizierungsmodul wurde auf der Basis des SQL Server Denali-Moduls entwickelt und setzt daher Regeln durch, die auf diesem Modul basieren. Wenn in Ihrem Projekt ältere Syntax verwendet wird, die in SQL Server Denali entfernt wurde, wird die Verifizierung nicht erfolgreich sein.
• Das Verifizierungsmodul versteht keine Objekte, auf die durch einen vollständig qualifizierten Namen mit drei oder vier Komponenten verwiesen wird. Das Modul wird eine Warnung oder einen Fehler melden, basierend auf den SQL Server-Regeln für die Auflösung zurückgestellter Namen. Weitere Informationen hierzu finden Sie unter bit.ly/pDStXE.

Wenn es diese Art von Einschränkungen gibt, können Sie die erweiterte Verifizierung auf Datei- oder Projektebene deaktivieren.

Nachdem Sie sich um sämtliche Warnungen und Meldungen gekümmert haben, die Ihnen während der Erstellung angezeigt wurden, müssen Sie überprüfen, ob der Code tatsächlich funktioniert.

Überprüfen Ihrer Quelle

Nach der Erstellung des Projekts müssen Sie den Code ausführen (und möglicherweise debuggen), bevor Sie diesen der Quellcodeverwaltung hinzufügen. Hierfür stehen Ihnen mehrere Optionen zur Verfügung, abhängig davon, an welcher Stelle im Entwicklungszyklus Sie sich befinden und was Sie tun möchten, wie in Abbildung 4 gezeigt.

Abbildung 4 Optionen für die Überprüfung Ihres Codes

Wenn Sie sich an dieser Stelle befinden...	Führen Sie folgende Schritte aus…
Sie haben mehrere Änderungen durchgeführt und möchten den Code debuggen.	Legen Sie das Datenbankprojekt als Startprojekt fest. Fügen Sie dem Projekt ein Skript hinzu, und schreiben Sie den Testfall, den Sie debuggen möchten. Öffnen Sie die Projekteigenschaften, navigieren Sie zur Registerkarte für das Debuggen, und wählen Sie das Skript als Startskript aus. Drücken Sie die Taste F5, um die Änderungen in der Datenbank zum Debuggen (vordefinierte LocalDB) zu implementieren, und starten Sie den Debugger. Der Debugger wird an der ersten Zeile des Startskripts angehalten werden.
Sie haben ein Anwendungsprojekt (eine Webanwendung oder eine .exe), die gespeicherte Prozeduren verwendet, die Sie geändert haben (und nun debuggen möchten).	Legen Sie das Anwendungsprojekt als Startprojekt fest. Ändern Sie die Konfigurationsdatei der Anwendung (web.config oder app.config), sodass diese auf die Datenbank zum Debuggen verweist (per Voreinstellung ist die Datenquelle=(localdb)\<Name der Lösung>; der anfängliche Katalog=<Projektname>). Drücken Sie die Taste F5, um die Anwendung auszuführen und die Datenbank zum Debuggen zu aktualisieren. Interagieren Sie mit der Anwendung, die getestet werden soll. Fügen Sie in die gespeicherte Prozedur, die Sie debuggen möchten, einen Haltepunkt ein.
Sie möchten die Datenbank mittels einer Anwendung debuggen, die auf die Datenbank zum Debuggen zugreift.	Legen Sie das Datenbankprojekt als Startprojekt fest. Ändern Sie die Konfigurationsdatei der Anwendung, sodass diese auf die Datenbank zum Debuggen verweist. Geben Sie auf der Registerkarte für das Debuggen in den Eigenschaften des Datenbankprojekts an, dass die Anwendung als externes Programm ausgeführt werden soll. Drücken Sie die Taste F5. Fügen Sie in die gespeicherte Prozedur, die Sie debuggen möchten, einen Haltepunkt ein. Interagieren Sie mit der Anwendung, die gestartet wurde, als Sie die Taste F5 gedrückt haben.
Sie haben mehrere Änderungen durchgeführt und möchten die Änderungen testen (und möglicherweise debuggen).	Fügen Sie dem Projekt ein Skript (nicht im Build) hinzu, und schreiben Sie die Tests, die Sie durchführen möchten. Drücken Sie die Tasten Strg+F5, um die Änderungen in der Datenbank zum Debuggen (vordefinierte LocalDB) zu implementieren. Markieren Sie die einzelnen Tests, und klicken Sie mit der rechten Maustaste auf die einzelnen Tests, um sie auszuführen (oder mit Debuggen auszuführen), um zu überprüfen, ob die Ergebnisse den erwarteten Ergebnissen entsprechen.

Migrieren von Änderungen

Wenn Ihr Code stabil ist, müssen Sie ihn zu einer Instanz migrieren, um ihn zu testen, sodass er schließlich von Ihren Kunden verwendet werden kann. Juneau verfügt über ein Modul für inkrementelle Updates, das auf der Basis des Unterschieds zwischen Ihrer Quelle und der Zieldatenbank ein Updateskript generiert. Obwohl es sich um ein einzelnen zugrunde liegendes Modul handelt, wird es auf drei verschiedene Arten innerhalb von Juneau veröffentlicht, um die Migrierung Ihrer Änderungen zu unterstützen, wie in Abbildung 5 gezeigt.

Abbildung 5 Optionen für die Migrierung Ihres Codes

Migrierungsszenario	Beschreibung
Implementierung der Änderungen in der Datenbank zum Debuggen	Schnelle Aktualisierung Ihrer Datenbank zum Debuggen mit den Änderungen aus Ihrem Projekt Verwendung der Einstellungen auf der Registerkarte für das Debuggen des Datenbankprojekts Ausführung bei Drücken der Tasten F5/Strg+F5 Veröffentlichung als ein MSBuild-Ziel
Veröffentlichung der Änderungen in einer getrennten Datenbank	Formelle Aktualisierung einer Datenbank aus einem Projekt Zur Migrierung oder Aktualisierung einer Umgebung Ausführung bei Klicken auf das Menü "Veröffentlichen" des Projekts Veröffentlichung als MSBuild-Ziel und mittels des Befehlszeilentools (sqlx.exe) Veröffentlichung als Anbieter für die Webbereitstellung (bit.ly/qBX0LK)
Vergleichen des Schemas und Synchronisierung der Änderungen zwischen den Datenbanken	Grafisches Tool für Differenzierung und Aktualisierung Aktualisierung einzelner Objektauswahlen Berücksichtung des Umgestaltungsprotokolls des Projekts bei der Anzeige von Unterschieden Ausführung durch die Auswahl von Kontextmenüs für ein Projekt oder eine Datenbank im neuen SQL Server-Knoten von Server Explorer

Zur Unterstützung dieser drei unterschiedlichen Szenarien stellt das Modul für inkrementelle Updates eine Reihe verschiedener Option für die Steuerung des Verhaltens bereit. Die voreingestellten Werte für diese Einstellungen werden mit der Zeit verändert, wenn das Team die einzelnen Szenarien optimiert. Während der Entwurfszeit ist es möglicherweise sinnvoller, wenn das Modul bei der Durchsetzung von Änderungen aggressiver ist und Datenverluste keine große Rolle spielen, da es sich um eine Datenbank zum Debuggen handelt. Obwohl es zahlreiche Optionen gibt, möchte ich Ihnen hier einige wenige Verhaltensweisen und die entsprechenden Optionen zeigen, wie in Abbildung 6 gezeigt.

Abbildung 6 Optionen für die Steuerung des Updateverhaltens

Verhalten	Option	Ergebnis
Datenverlust	Inkrementelle Bereitstellung bei möglichen Datenverlusten blockieren	Das Modul für die inkrementelle Aktualisierung hält die Ausführung an, wenn eine Tabelle Daten enthält und das Skript später eine destruktive Änderung durchführt. Eine destruktive Änderung ist beispielsweise die Entfernung einer Spalte oder die Änderung eines Typs (bigint zu int).
	Datenbank vor der Bereitstellung sichern	Das Modul erstellt ein Skript für die Datenbanksicherung, bevor Änderungen durchgeführt werden.
Generieren von Drops	Datenbank stets neu erstellen	Das Updateskript wird so geschrieben, dass es erkennt, ob die Datenbank vorhanden ist. Wenn dies der Fall ist, wird diese auf den Modus für einen einzelnen Benutzer festgelegt und ein Drop durchgeführt.
	Drops für Objekte im Ziel, jedoch nicht in der Quelle	Diese Option ist ein "Hammer", mit dem Drops für alle Objekte in der Zieldatenbank durchgeführt werden, die nicht auch in der Quelldatenbank vorhanden sind. Diese Option setzt sämtliche Datenverlustoptionen außer Kraft.
	Drops für Beschränkungen, Indexe, DML-Auslöser	Behandelt Beschränkungen, Indexe und DML-Auslöser, als ob Sie Teil der Tabelle oder der Ansicht sind. Daher führt die Entfernung dieser Objekte aus dem Projekt zu einem Drop des entsprechenden Objekts im Ziel.
	Drops für Genehmigungen, erweiterte Eigenschaften	Diese Option behandelt diese Objekte, als ob sie Teil des übergeordneten Objekts sind, vergleichbar der vorangegangenen Option. Daher werden für Objekte, die nur im Ziel, jedoch nicht in der Quelle vorhanden sind, Drops durchgeführt.
Überprüfen neuer Beschränkungen	Neue Beschränkungen prüfen	Wenn neue externe Schlüssel und Prüfungsbeschränkungen erstellt werden, können diese prüfen, ob die vorhandenen Daten der Beschränkung entsprechen. Die Datenprüfung für neue Beschränkungen wird an das Ende des Bereitstellungsskripts gestellt, sodass eine Beschränkungsverletzung nicht zu einem Fehler während der Bereitstellung führt.
Transaktionen	Transaktionsskript einschließen	Bei Aktivierung dieser Option versucht das Modul, das generierte Skript innerhalb einer Transaktion einzubinden. Da einige Objekte nicht innerhalb einer Transaktion verwaltet werden können, werden Teile des Skripts möglicherweise nicht innerhalb der Transaktion ausgeführt.

Die Erstellung eines Skripts für inkrementelle Updates ist bei der Migrierung von Änderungen aus einer Quell- in eine Zieldatenbank sehr nützlich. Unabhängig davon, wie genau das Skript für das inkrementelle Update auch ist, ist es manchmal schwierig, genau zu ermitteln, was im Skript passiert oder was das Skript ausführt. Um die Zusammenfassung und das Verständnis des inkrementellen Skripts zu unterstützen, erstellt Juneau einen Vorschaubericht, der mögliche Probleme für die Aktionen des Skripts markiert. Außerdem werden die Aktionen zusammengefasst, die durch das Skript aufgeführt werden. Beispielsweise können Sie Ihr Projekt zur vordefinierten LocalDB-Instanz wie folgt veröffentlichen:

1. Öffnen Sie das Fenster für die Hintergrundaktivitäten, indem Sie auf Anzeigen | Weitere Fenster | Datenbankaktivitätsmonitor klicken.
2. Klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie "Veröffentlichen" aus.
3. Füllen Sie das Dialogfeld "Veröffentlichen" wie in Abbildung 7 gezeigt aus.
4. Klicken Sie auf "Veröffentlichen".

Abbildung 7: Dialogfeld für das Veröffentlichen von Datenbanken

Öffnen Sie nach der Veröffentlichung den Veröffentlichungsschritt, und klicken Sie auf den Link "Plan anzeigen". Es wird ein Bericht wie der in Abbildung 8 gezeigte Bericht angezeigt.

Abbildung 8. Der Vorschaubericht für die Bereitstellung

Wie Sie sehen, zeigt der Bericht an, dass die beiden Tabellen (wir haben den Fehler in der Tabelle ExtendedVerificationDemo behoben) und die Prozedur, die wir an früherer Stelle geschrieben haben, während der Ausführung des Skripts erstellt werden. Der Abschnitt für die Markierungen ist leer. Sie können jedoch sehen, dass der Bericht Aktionen markieren wird, die die Leistung wesentlich beeinträchtigen oder zu Datenverlusten führen. Wenn wir nur ein Skript generiert und nicht veröffentlicht hätten, könnten wir diesen Bericht für die Verifizierung des Skripts vor dessen Ausführung verwenden.

Integrierte Entwicklung

Bisher haben wir über Möglichkeiten für die Verwendung des Datenbankprojekts zur deklarativen Entwicklung von Code außerhalb einer ausgeführten Datenbank gesprochen. Diese Technologie ist äußerst nützlich, wenn Sie in Teamumgebungen arbeiten. Manchmal möchten Sie jedoch einfach nur mit einem Liveserver interagieren! Microsoft weiß, dass Liveserver für Entwickler wichtig sind, und hat daher eine umfangreiche, integrierte Umgebung geschaffen, die sich an den Bedürfnissen von Entwicklern orientiert. Um dies zu zeigen, öffnen wir die Datenbank, zu der wir gerade veröffentlich haben. So stellen Sie eine Verbindung mit dieser Datenbank her

1. Klicken Sie auf das Menü "Ansicht".
2. Wählen Sie "Server Explorer" aus.
3. Klicken Sie mit der rechten Maustaste auf den SQL Server-Knoten.
4. Wählen Sie "SQL Server hinzufügen" aus.
5. Füllen Sie das Verbindungsdialogfeld mit (localdb)\v11.0 aus.
6. Navigieren Sie zur gerade veröffentlichen Datenbank MsdnDemo, wie in Abbildung 9 gezeigt.

Abbildung 9 Datenbank MsdnDemo im neuen SQL Server-Knoten in Server Explorer

Als Erstes werden Sie wahrscheinlich feststellen, dass die Struktur der Struktur in SSMS sehr ähnlich ist. Dies sollte auch der Fall sein. Das Team wollte den Lernaufwand bei der Migrierung zu Juneau begrenzen. Sie können direkt in der Struktur einen T-SQL-Abfrage-Editor öffnen und mit dem Schreiben von Code beginnen, wie Sie es auch sonst tun würden. Dieser Editor ist der gleiche optimierte Editor, den wir bereits erwähnt haben. Anders als im Fall einiger der SSMS-Funktionen ist die Juneau-Struktur ausdrücklich für Entwickleraktionen bestimmt. Wenn Sie beispielsweise mit der rechten Maustaste auf die Tabelle "Kunde" klicken und "Löschen" auswählen, wird Ihnen ein Dialogfeld mit dem gleichen Vorschaubericht angezeigt, den Sie bereits gesehen haben. In diesem Fall wird Ihnen jedoch die Warnung angezeigt, dass die Prozedur dbo.CreateCustomer beschädigt werden wird, wenn der Drop ausgeführt wird, wie in Abbildung 10 gezeigt.

Abbildung 10 Dialogfeld für die Datenbankaktualisierungsvorschau

** Warnings

     The object [dbo].[CreateCustomer] will be broken if the

       change is executed.

 

** Highlights

     Tables that will be rebuilt

       None

     Clustered indexes that will be dropped

       None

     Clustered indexes that will be created

       None

     Possible data issues

       None

 

** User actions

     Drop

       [dbo].[Customer] (Table)

 

** Supporting actions

Ein ähnlicher Bericht wird bei der Umbenennung der Tabelle generiert. In beiden Fällen werden Sie über die Auswirkungen der Änderungen informiert, bevor die Aktionen ausgeführt werden. Mithilfe dieses Berichts können Sie erkennen, welche Auswirkungen die Änderungen auf die Datenbank haben und welche Fehler Sie möglicherweise beheben müssen (bzw. was Sie möglicherweise löschen müssen), bevor Sie die Änderungen anwenden.

Wenn Sie den Löschvorgang abbrechen, anschließend mit der rechten Maustaste auf die Tabelle "Kunde" und auf "Designer anzeigen" klicken, wird Ihnen der gleiche Tabellen-Designer angezeigt, den Sie bereits aus dem Projektsystem kennen, außer dass dieser nun über die Definition der Tabelle gehostet wird, die vom Server abgerufen wurde. Wie erwartet, verfügt der Designer über eine Tabellenanweisung CREATE, die das gleiche deklarative Programmiermodell wie das Projektsystem verwendet. Benennen Sie im Designer die Spalte "Id" zu "CustomerId" um, und fügen Sie eine zweite int-Spalte mit dem Namen "Age" hinzu. Wenn Sie nun die Fehlerliste betrachten, sehen Sie die Warnung, dass CreateCustomer durch die Umbenennung der Spalte beschädigt wurde, wie in Abbildung 11 gezeigt.

Abbildung 11 Fehler aufgrund der Umbenennung einer Spalte

Diese Fehler können Sie mittels "Code anzeigen" auf der Prozedur CreateCustomer oder mittels Doppelklick auf die Warnung beheben, indem Sie die insert-Anweisung ändern, sodass die Spaltennamen aktualisiert werden, und @param2 als Wert für die Spalte "Age" bereitstellen. An diesem Punkt werden Ihnen zwei Fenster angezeigt (ein Fenster für die Quelle und ein Fenster für den Designer), in denen Ihnen die aus der Datenbank abgerufenen deklarativen Objektdefinition angezeigt werden, die die Änderungen für die Objekte auf dem Server definieren. Wenn Sie auf die Schaltfläche für das Aktualisieren der Datenbank klicken, wird Ihnen der nun vertraute Bericht angezeigt, in dem Sie darüber informiert werden, dass die Spalte umbenannt und sowohl die Tabelle als auch die Prozedur geändert wird. Führen Sie das Skript aus, indem Sie auf "Datenbank aktualisieren" klicken, und navigieren Sie anschließend in Server Explorer zur Tabelle "Kunde". Ihnen wird die aktualisierte Struktur angezeigt, die die Spalten CustomerId und Age enthält.

Die integrierte Entwicklungsumgebung in Server Explorer gibt Ihnen hervorragende Möglichkeiten zur Kontrolle, da das gleiche deklarative Programmiermodell unterstützt und das Verfahren für Onlineänderungen mittels Warnungen und Fehlerberichten in Echtzeit optimiert wird, während Sie die Änderungen durchführen.

So erhalten Sie Juneau

Juneau ist in der Version SQL Server Denali CTP3 enthalten. Es wird auch als unabhängiger Webdownload verfügbar sein und kann in vorhandene Installationen von Visual Studio 2010 und der nächsten Version von Visual Studio integriert werden. Außerdem verfügt Juneau über ein eigenes Befehlszeilentool-Installationsprogramm für die Veröffentlichung von Datenbanken, ohne dass die Installation von Visual Studio erforderlich ist, sowie für automatisch mittels Team Foundation Server erstellte Szenarien.

Einführung in SQL Server Express LocalDB

SQL Server Express LocalDB (oder kurz LocalDB) ist im Grunde die nächste Generation von SQL Express User Instances, ohne dass Sie jedoch eine SQL Express-Instanz auf Ihrem Desktop explizit verwalten müssen. LocalDB verfügt über keinen Hintergrunddienst, der eine benannte Instanz hostet. Stattdessen ermöglicht es Entwicklern das Definieren von Instanzen mit angepassten Namen und die anschließende Interaktion mit diesen. Wenn eine LocalDB-Instanz gestartet wird, wird diese als ein Prozess unter den Anmeldeinformationen des Benutzers ausgeführt, der sie gestartet hat. Wenn Sie eine LocalDB-Instanz gestartet haben, wird Ihnen z. B. im Task-Manager der Prozess sqlservr.exe angezeigt, der unter Ihren eigenen Anmeldeinformationen ausgeführt wird. Dies ist sehr nützlich, da Sie so keine Einstellungen durchführen müssen, um den T-SQL-Code zu debuggen! Nach dem Starten der Instanz verhält sich diese wie jede andere SQL Express-Instanz. Wenn die Instanz über einen bestimmten Zeitraum nicht verwendet wird, wird sie geschlossen, sodass die Leistung des Computers nicht durch eine SQL Server-Instanz im Leerlauf beeinträchtigt wird.

Die LocalDB-Installation verfügt über ein Befehlszeilentool, mit dem die von Ihnen erstellten LocalDB-Installation verwaltet werden können. Sie können beispielsweise eine neue LocalDB-Instanz namens LocalDBDemo erstellen, indem Sie die folgenden Schritte ausführen:

C:\Program Files\Microsoft SQL Server\110\Tools\Binn>SqlLocalDB.exe create LocalDBDemo

Lokale Datenbankinstanz "LocalDBDemo", erstellt mit Version 11.0.

Nach der Erstellung der Instanz können Sie diese mittels des Befehlszeilentools starten. Alternativ können Sie mittels Juneau, SQL Server Management Studio (SSMS) oder Ihre Anwendung eine Verbindung zur Instanz herstellen. Da LocalDB-Instanzen nicht im Speicher gehalten werden, kann auf sie nicht mittels des (lokalen) Präfixes zugegriffen werden, das für Instanzen auf dem lokalen Computer verwendet wird. Stattdessen muss (localdb) verwendet werden. In diesem Beispiel geben Sie in Juneau (localdb)\LocalDBDemo ein, um eine Verbindung zur Instanz herzustellen und diese zu verwalten.

Bei der Erstellung einer neuen Instanz wird innerhalb des Benutzerprofils ein neues Verzeichnis erstellt, und die vier integrierten Datenbanken (master, tempdb, msdb und model) werden in diesem Verzeichnis gespeichert. Per Voreinstellung werden alle neuen Datenbanken im Verzeichnis für die Instanz gespeichert. In unserem Beispiel ist das Verzeichnis:

C:\Users\user1\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\LocalDBDemo

Wenn Sie keine angepasste Instanz erstellen möchten, können Sie die vordefinierte integrierte LocalDB-Instanz namens v11.0 verwenden. Um auf die Instanz zuzugreifen, registrieren Sie in Juneau einfach eine Verbindung mit "(localdb)\v11.0". Die Instanz wird automatisch durch LocalDB für Sie erstellt.

Da LocalDB neu ist, ist ein Patch für das Microsoft .NET Framework 4 erforderlich, um das (LocalDB)-Präfix beim Zugriff auf eine Instanz über SSMS oder verwalteten Anwendungscode verwenden zu können. Die Installation von Juneau enthält diesen Patch. Die Unterstützung für das Präfix wird in die nächste Version von .NET Framework integriert.

Datenbankentwickler sehen sich einem ähnlichen Problem gegenüber, das auch Webentwickler hatten (und das durch IISExpress für diese gelöst wurde): Die Entwicklung und das Debuggen von Code, der einen Server für die Ausführung benötigt, ohne dass lokal auf dem Entwicklungscomputer das vollständige Serverprodukt ausgeführt werden muss. LocalDB stellt eine Lösung für Datenbankentwickler bereit. Da LocalDB einen wichtigen Teil der Datenbankentwicklung darstellt, wird es während der Installation von Juneau auf Ihrem Computer installiert. Wenn einer Lösung ein Datenbankprojekt hinzugefügt wird, erstellt Juneau eine neue LocalDB-Instanz, die nach der Lösung benannt wird, und erstellt innerhalb dieser Instanz eine Datenbank für jedes Datenbankprojekt. Juneau erstellt für jedes Datenbankprojekt die Daten- und Protokolldatei in einem Verzeichnis innerhalb des Projektverzeichnisses. Weitere Informationen zu LocalDB finden Sie unter go.microsoft.com/fwlink/?LinkId=221201.

Jamie Laflen ist ein Entwickler, der für SQL Server Developer Tools arbeitet. Zuvor arbeitete er für Visual Studio Database Projects.

Barclay Hill ist Senior Program Manager für SQL Server Developer Tools. Zuvor arbeitete er für Visual Studio Database Projects.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Jeffrey Davis, Mike Kaufman, Dave Langer, Genevieve Orchard und Patrick Sirr.