Ich habe versucht, eine Antwort auf diese Frage zu strukturieren, seit sie ursprünglich veröffentlicht wurde. Dies ist schwierig, da es in VS2010 nicht darum geht, die Funktionen und Vorteile des Tools zu beschreiben. Hier geht es darum, den Leser zu überzeugen, seine Herangehensweise an die Datenbankentwicklung grundlegend zu ändern. Nicht einfach.
Es gibt Antworten auf diese Frage von erfahrenen Datenbankexperten mit einem Hintergrundmix aus DBA, Entwickler / DBA, OLTP und Data Warehousing. Es ist für mich nicht sinnvoll, dies in einer Sitzung für alle Aspekte der Datenbankentwicklung zu erörtern. Daher werde ich versuchen, ein bestimmtes Szenario zu begründen.
Wenn Ihr Projekt diese Kriterien erfüllt, gibt es meines Erachtens einen überzeugenden Fall für VS2010:
- Ihr Team verwendet VS2010 für die Anwendungsentwicklung.
- Ihr Team verwendet TFS für die Quellcodeverwaltung und das Build-Management.
- Ihre Datenbank ist SQL Server.
- Ihr Team hat bereits automatisierte VS-Tests oder ist daran interessiert.
Wenn Sie VS2010 für die Datenbankentwicklung auswerten, ist Ihre Bibel das Visual Studio-Datenbankhandbuch der Visual Studio ALM Rangers . Alle folgenden Zitate, auf die nicht verwiesen wird, stammen aus diesem Dokument.
Auf geht's dann ...
Warum unterscheidet sich der Datenbankentwicklungsprozess von der Anwendungsentwicklung?
Daten. Ohne diese lästigen Daten wäre die Datenbankentwicklung ein Kinderspiel. Wir könnten einfach alles bei jeder Veröffentlichung TROPFEN und dieses lästige Änderungsmanagement vergessen.
Das Vorhandensein von Daten erschwert den Datenbankänderungsprozess, da die Daten häufig migriert, transformiert oder neu geladen werden, wenn Änderungen durch Anwendungsentwicklungsbemühungen vorgenommen werden, die sich auf die Form der Datenbanktabellen oder anderer Datenschemata auswirken. Während dieses Änderungsprozesses müssen Daten zur Produktionsqualität und der Betriebszustand vor Änderungen geschützt werden, die die Integrität, den Wert und den Nutzen für das Unternehmen gefährden können.
Was ist los mit SSMS?
Es hat einen Grund, warum es SQL Server Management Studio heißt. Als eigenständiges Tool ist es unpraktisch, Ihre Entwicklungsbemühungen zu verwalten, wenn Sie anerkannte Best Practices befolgen.
Nur mit Skripten müssen Sie sowohl Objektdefinitionen (z. B. ein CREATE TABLE-Skript) als auch Änderungsskripten (z. B. ALTER TABLE) pflegen und hart daran arbeiten, sicherzustellen, dass sie synchron bleiben, um bewährte Methoden der Quellcodeverwaltung in Ihrer Entwicklung sinnvoll anzuwenden.
Die Versionskette für Änderungen an einer Tabelle wird ziemlich schnell ziemlich blöd. Ein sehr vereinfachtes Beispiel:
-- Version 1
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20))
-- Version 2
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50))
-- Version 3
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))
Ab Version 3 enthält das Datenbankänderungsskript Folgendes:
ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)
Wenn es sich bei der Live-Version dieser Datenbank um Version 1 und bei unserer nächsten Version um Version 3 handelt, ist nur das folgende Skript erforderlich. Stattdessen werden beide ALTER-Anweisungen ausgeführt.
ALTER TABLE dbo.Widget ADD Description VARCHAR(100)
5 Jahre von 4 Wochen Sprints summieren sich zu einigen unterhaltsamen Versionsskripten und erfordern zusätzlichen Personaleinsatz, um die Auswirkungen auf die Bereitstellungszeit zu minimieren.
Stimmt etwas mit SSMS nicht? Nein, es ist gut für das, wofür es gut ist, SQL Server zu verwalten und zu verwalten. Es gibt nicht einmal vor, einem Datenbankentwickler bei der (manchmal) sehr komplexen Aufgabe des Änderungsmanagements behilflich zu sein.
Wenn Sie nicht jede Version der Datenbank aus dem Quellcode erstellen und auf eine zukünftige Version aktualisieren können, ist Ihre Quellcodeverwaltung fehlerhaft. Wenn Sie das nicht glauben, fragen Sie Eric Sink .
Was ist mit SSMS + <- Schemavergleichstool einfügen ->?
Dies ist definitiv ein Schritt in die richtige Richtung und erspart einen Großteil des manuellen Aufwands für die Pflege von Skripten. Aber (und es ist ein großes, aber), in der Regel sind manuelle Schritte erforderlich.
Die beliebten Schemavergleichstools können vollständig automatisiert und in den Erstellungsprozess integriert werden. Meiner Erfahrung nach ist es jedoch üblich, einen Vergleich manuell durchzuführen, die resultierenden Skripte zu überprüfen, in die Quellcodeverwaltung einzuchecken und dann manuell auszuführen, um sie bereitzustellen. Nicht gut.
Immer wenn wir fehlbaren Menschen in den Bau- oder Bereitstellungsprozess involviert werden müssen, führen wir Risiken ein und machen den Prozess nicht wiederholbar.
Wenn Sie und Ihr Team zu den wenigen gehören, die über einen vollautomatischen Schema-Vergleich und eine vollautomatische Bereitstellung verfügen, können Sie sich freuen! Ihr seid am ehesten offen für die Vorteile, die VS2010 zu bieten hat:
- Sie haben bereits akzeptiert, dass manuelle Schritte gefährlich sind.
- Sie sehen den Wert der Automatisierung.
- Sie sind bereit, die dafür erforderliche Zeit zu investieren.
Wenn Sie keinen Build in einem einzigen Schritt erstellen oder in einem einzigen Schritt bereitstellen können, ist Ihr Entwicklungs- und Bereitstellungsprozess unterbrochen. Wenn Sie das nicht glauben, fragen Sie Joel Spolsky .
Warum VS2010?
Die Frage, die @NickChammas gestellt hat, ist nach Killer-Features zu suchen, die zeigen, warum VS2010 ein Game Changer für die Datenbankentwicklung ist. Ich glaube nicht, dass ich das auf dieser Grundlage begründen kann.
Vielleicht komisch, wenn andere Fehler in diesem Tool sehen, sehe ich starke Gründe für die Annahme:
- Sie müssen Ihren Ansatz ändern.
- Sie und Ihr Team werden gezwungen sein, anders zu arbeiten.
- Sie müssen die Auswirkungen jeder Änderung ausführlich bewerten.
- Sie werden dazu geführt, dass jede Änderung idempotent wird .
Wenn Sie der einzige DBA in einem Projekt sind, der alle Änderungen an der Datenbank verwaltet, muss diese Argumentation absurd klingen. Wenn Sie jedoch der Meinung sind, dass @BrentOzar einen Punkt hat und eine der neuen Regeln lautet, dass Jeder der DBA ist , müssen Sie die Datenbankänderungen auf eine Weise steuern, mit der jeder Entwickler im Team arbeiten kann.
Die Übernahme von Datenbankprojekten kann für einige Entwickler eine mentale Veränderung ( alte Gewohnheiten sind schwer zu brechen ) oder zumindest eine Änderung des Prozesses oder der Arbeitsabläufe erforderlich machen. Entwickler, die Datenbankanwendungen entwickelt haben, bei
denen die Produktionsdatenbank die aktuelle Version der Datenbank darstellt, müssen einen quellcodebasierten Ansatz anwenden, bei dem der Quellcode zum Vehikel wird, an dem Änderungen an Datenbanken vorgenommen werden . In Visual Studio-Datenbankprojekten sind das Projekt und der Quellcode die "One Version of the Truth" für das Datenbankschema und werden mithilfe von SCM-Workflows verwaltet, die wahrscheinlich bereits vom Entwickler oder der Organisation für andere Teile ihres Anwendungsstapels verwendet werden. Für die Daten bleibt die Produktionsdatenbank die "Eine Version der Wahrheit", wie sie sein sollte.
Wir sind an der grundlegenden Veränderung angelangt, die erforderlich ist, um den VS2010-Ansatz für die Datenbankentwicklung erfolgreich umzusetzen…
Behandle deine Datenbank als Code
Kein Ändern der Live-Datenbank mehr. Jede Datenbankänderung folgt demselben Muster wie eine Anwendungsänderung. Quelle ändern, erstellen, bereitstellen. Dies ist keine vorübergehende Richtungsänderung von Microsoft, dies ist die Zukunft für SQL Server . Datenbank als Code ist da, um zu bleiben.
Der Datenbankentwickler definiert die Form des Objekts für die Version der Anwendung und nicht, wie das vorhandene Objekt im Datenbankmodul in die gewünschte Form geändert werden soll. Sie fragen sich möglicherweise: Wie wird dies für eine Datenbank implementiert, die bereits die Kundentabelle enthält? Hier kommt die Deployment Engine ins Spiel. Wie bereits erwähnt, verwendet die Bereitstellungsengine die kompilierte Version Ihres Schemas und vergleicht sie mit einem Datenbankbereitstellungsziel. Das differenzierende Modul erstellt die erforderlichen Skripts, um das Zielschema so zu aktualisieren, dass es der Version entspricht, die Sie aus dem Projekt bereitstellen.
Ja, es gibt andere Tools, die einem ähnlichen Muster folgen, und für Projekte außerhalb der von mir auferlegten Einschränkungen sind sie gleichermaßen zu berücksichtigen. Wenn Sie jedoch mit Visual Studio und Team Foundation Server ALM arbeiten, können sie meiner Meinung nach nicht miteinander konkurrieren.
Was ist los mit VS2010-Datenbankprojekten?
- Sie sind nicht perfekt . Wenn Sie sich jedoch der Einschränkungen und Problembereiche bewusst sind, können Sie diese umgehen.
- Komplexe Datenbewegungen erfordern weiterhin Sorgfalt und Aufmerksamkeit, werden jedoch mit Skripten vor und nach der Bereitstellung berücksichtigt.
Edit: Also, was ist dein Punkt dann?
@ AndrewBickerton erwähnte in einem Kommentar, dass ich die ursprüngliche Frage nicht beantwortet habe, und ich werde versuchen, zusammenzufassen: "Warum sollte ich Visual Studio 2010 über SSMS für meine Datenbankentwicklung verwenden?" Hier.
- SSMS ist kein Datenbankentwicklungstool. Ja, Sie können TSQL mit SSMS entwickeln, es bietet jedoch nicht die umfangreichen IDE-Funktionen von VS2010.
- VS2010 bietet ein Framework, um Ihre Datenbank als Code zu behandeln.
- VS2010 bringt statische Code-Analyse in Ihren Datenbankcode.
- VS2010 bietet Ihnen die Tools, um den Build-Deploy-Test-Zyklus vollständig zu automatisieren.
- SQL2012 und Visual Studio vNext erweitern die Funktionen von Datenbankprojekten. Machen Sie sich jetzt mit VS2010 vertraut, und Sie haben einen Vorsprung auf die Entwicklungstools der nächsten Generation für Datenbanken.