Visual Studio 2010 führt Datenbankprojekte und eine ganze Reihe verwandter Funktionen ein, die angeblich die Datenbankentwicklung erleichtern. Ich habe SQL Server Management Studio (SSMS) viele Jahre lang verwendet, um meine Datenbankentwicklung ohne Probleme durchzuführen.
Eigentlich war ich mit VS2010 ein bisschen unterfordert, um ehrlich zu sein. Ich denke, ein Skript zum Erstellen von Tabellen und Dateien für gespeicherte Prozeduren der alten Schule ist einfacher zu bearbeiten. Wenn Sie eine Schemaverwaltung benötigen, können Sie Redgate SQL Compare Pro für ein paar hundert Dollar erwerben.
Wenn Sie wirklich ein Datenbankmodellierungswerkzeug benötigen, machen Powerdesigner oder sogar Erwin einen viel besseren Job, obwohl sie nicht besonders billig sind.
Obwohl ich SSMS bevorzuge, habe ich beide verwendet. Einige Vor- und Nachteile:
SSMS verfügt über eine Benutzeroberfläche, die für die SQL-Entwicklung einfach funktioniert. Das Erstellen und Verwenden von Erstellungsskripten ist viel bequemer, als die Reifen VS2010 Sie zum Durchspringen zwingen. Viel, viel flexibler (+ SSMS).
VS2010 verfügt über eine grundlegende Schemaverwaltung (d. H. Differenz-/Patch-Skriptgenerierung) (+ VS2010). Es ist jedoch nicht so gut und hat einige Mängel. Zum Beispiel entspricht es Einschränkungen für den Namen. Wenn Sie für eine Spalte Überprüfungs- oder Standardeinschränkungen haben, ohne diese zu benennen, generiert SQL Server hinter den Kulissen einen zufälligen Namen. Dies verwirrt VS2010, wenn Sie das Skript auf einem anderen Computer installieren, da die Einschränkungen möglicherweise unterschiedliche Namen haben. Redgate ist billiger und besser. (+ VS2010, aber fehlerhaft).
VS2010 ist wirklich ungeschickt - Sie müssen eine Datei für jede Tabelle oder jedes andere DB-Objekt haben. Im Wesentlichen müssen Sie die Dinge auf die VS2010-Art erledigen, was ziemlich umständlich ist. (- VS2010)
VS2010 ist auch etwas zerbrechlich und die Integration der Quellcodeverwaltung ist unzuverlässig. Selbst in einer einfachen Datenbank ist jede Tabelle, Einschränkung, gespeicherte Prozedur, jeder Index und jedes andere Datenbankobjekt eine eigene Datei. Dateien werden dem Projekt ständig hinzugefügt, viel schneller als bei einem typischen Programmierprojekt mit (sagen wir) C #. Bei optimistischer Parallelität besteht die Tendenz, dass Dateien stillschweigend aus dem Projekt entfernt werden, wenn die Eincheckvorgänge nicht mehr synchron sind. Selbst bei guter Teamdisziplin ist das Feedback der Benutzeroberfläche zum Status sehr schlecht. Dies wäre eine Katastrophe in einem komplexen Modell. (-VS2010 - Ich würde das fast als einen atemberaubenden Fehler für ein großes Projekt betrachten).
SSMS wird mit SQL Server geliefert - kann den Preis nicht übertreffen (+ SSMS).
VS2010 verfügt immer noch nicht über ein geeignetes Repository wie PowerDesigner oder Oracle Designer. Sie können das Datenmodell nicht einfach abfragen, ohne es in einer Datenbank zu installieren. (- VS2010).
Insgesamt würde ich VS2010 mit einem B- bewerten. Bei einem relativ einfachen Datenbankprojekt mit zwei Faktentabellen und etwa 15 Dimensionen war es ungeschickt.
Das größte Datenmodell, das ich jemals gemacht habe, war für ein Gerichtsverfahrensverwaltungssystem mit etwa 560 Tabellen. Ich würde VS2010 nicht für ein Projekt dieser Größe empfehlen (das habe ich in Oracle Designer gemacht). Im Wesentlichen versucht es, klug zu sein, und das Paradigma funktioniert nicht wirklich gut. Mit einem erstklassigen Modellierungswerkzeug wie PowerDesigner oder der manuellen Erstellung von Tabellenskripten sind Sie besser dran.
SSMS ist einfach und zuverlässig, aber manuell. Sie haben so ziemlich unendlich viel Kontrolle darüber, wie Sie das Modell verwalten möchten. Kombinieren Sie es mit einem Schema-Manager wie Redgate SQL Compare und möglicherweise einem anständigen Modellierungswerkzeug wie PowerDesigner, und Sie haben ein viel besseres Paket als VS2010.
Zusammenfassung Ich bin mir nicht sicher, ob ich außer (vielleicht) der Integration in VS-Lösungen, die andere Projekte enthalten, irgendwelche Killerfunktionen oder -vorteile nennen könnte. Wenn Sie bereits über VS2010 Premium oder Ultimate verfügen, erhalten Sie ein etwas fehlerhaftes Datenbankentwicklungstool, das in Ihre .Net-Toolkette integriert ist. Es werden DB-Projekte in Ihre VS-Lösung integriert, sodass Sie damit zumindest Sproc-Bereitstellungsskripts erstellen können.
Da VS jedoch kein nennenswertes Modellierungswerkzeug hat, ist PowerDesigner oder sogar Erwin in dieser Hinsicht besser. Die Schemaverwaltung von Redgate ist viel besser und SQL Compare Pro ist recht günstig (ca. 400 GBP IIRC). IMHO SSMS funktioniert viel besser für die T-SQL-Entwicklung, aber Sie können es sicherlich mit VS2010 tun.
VS2010 Premium ist nicht viel billiger als ein erstklassiges Datenbankmodellierungswerkzeug, und VS2010 Ultimate ist mindestens genauso teuer. Auf Kosten einer engen Integration in Ihr VS-Projekt könnten Sie mit Tools von Drittanbietern wahrscheinlich bessere Ergebnisse erzielen.
Eine Alternative
Ich denke, man sollte VS2010 nicht zu sehr verschmutzen, ohne mindestens eine Alternative vorzuschlagen und die Vor- und Nachteile zu skizzieren. Zu diesem Zweck gehe ich von einem großen Projekt aus. Obwohl ich heutzutage hauptsächlich A/P-Arbeiten mache, war ich an einem Projekt mit mehr als 100 Mitarbeitern beteiligt, bei dem ich das Datenmodell (und einige Entwicklungsarbeiten) durchgeführt habe, und an einigen anderen im Bereich von 10 Mitarbeitern, bei denen ich hauptsächlich gearbeitet habe als Analyst oder Entwickler. Meistens arbeite ich heutzutage an Data Warehouse-Systemen, aber die größeren Projekte waren hauptsächlich Anwendungen. Basierend auf meinen Erfahrungen mit verschiedenen Werkzeugen sind hier einige Vorschläge für eine alternative Werkzeugkette:
Vorteile : Bessere Datenbankmodellierung und Schemaverwaltung als VS2010, besseres Versionskontrollsystem, einfachere Anpassung des Build- und Projektworkflows, bessere Verwaltung von Spezifikationen und Dokumentation.
Nachteile : Mehr Aufwand für die Integration von Tools, eingeschränkte DB-Integration in den Build-Prozess.
Annahmen : Nimmt an, dass die Steuerung des Änderungs-/Freigabeprozesses wichtiger ist als das automatisierte oder eng integrierte Freigabemanagement für DB-Schemas. Es wird auch davon ausgegangen, dass die automatisierte DB-Schemaverwaltung nicht 100% zuverlässig ist.
Nicht besonders hochtechnologisch oder geschickt integriert, aber für ein komplexes Projekt interessieren Sie sich wahrscheinlich mehr für Kontrolle als für niedliche automatisierte Funktionen. Ich würde behaupten, dass Sie mit einer Reihe von Best-of-Breed-Tools und dem für die Integration erforderlichen Home-Brew-Build- und Test-Scripting besser dran sind. Versuchen Sie einfach, den Build (a) relativ einfach zu verstehen und (b) vollständig automatisiert zu halten.
Qualitätssicherung bei DB-Patches. In einem großen Schema möchten Sie möglicherweise einen manuellen Patch-Prozess für Live-Systeme durchführen, insbesondere wenn die Patches eine Datenmigration beinhalten. Beispielsweise kann es wünschenswert sein, Roll-Forward- und Roll-Back-Skripte zu haben, um das Zurücksetzen einer Änderung bei Bedarf zu unterstützen. In diesem Fall möchten Sie eine Möglichkeit haben, um zu testen, ob der Patch tatsächlich ordnungsgemäß funktioniert. Wenn Sie das Datenbankschema in einem Repository verwalten, können Sie die Skripts testen, indem Sie sie vor Datenbanken einrichten und eine Referenzdatenbank aus dem Repository generieren. Das Ausführen des Patch-Skripts in der Vorher-Datenbank sollte es mit dem Repositiry-Modell synchronisieren. Ein Schema-Vergleichstool kann verwendet werden, um dies zu testen.
Ich habe in letzter Zeit viel mehr Data Warehouse- und Integrationsarbeit geleistet als die maßgeschneiderte Anwendungsentwicklung, daher stoße ich in den meisten Fällen häufiger darauf als ein Entwicklungsteam. Projektmanagement-Tools und -Methoden leisten jedoch nur sehr schlechte Arbeit bei der Verwaltung externer Stakeholder. In einem Integrationsprojekt wie einem Data Warehouse möchte ich wirklich ein Projektmanagement-Tool sehen, das externe Abhängigkeiten (d. H. Solche, die ich nicht kontrolliere) angesichts der Programmverwaltung wirklich pusht. Bei jedem nicht trivialen Integrationsprojekt sind die externen Abhängigkeiten bei weitem die größten Treiber für Zeitverschwendung.
Ich habe damit gespielt, wie man eine Antwort auf diese Frage strukturiert, seit sie ursprünglich veröffentlicht wurde. Dies ist schwierig, da es bei 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 Datenbankprofis mit einem Hintergrundmix aus DBA, Entwickler/Datenbank und beiden OLTP und Data Warehousing). Es ist für mich nicht sinnvoll, dies für jede Facette der Datenbank anzugehen Entwicklung in einer Sitzung, also werde ich versuchen, für ein bestimmtes Szenario einzutreten.
Wenn Ihr Projekt diese Kriterien erfüllt, gibt es meines Erachtens einen überzeugenden Fall für VS2010:
Wenn Sie VS2010 für die Datenbankentwicklung evaluieren, ist Ihre Bibel Visual Studio Database Guide von Visual Studio ALM Rangers . Alle folgenden Zitate, die keine Referenzen haben, stammen aus diesem Dokument.
Los geht's dann ...
Daten. Ohne diese lästigen Daten wäre die Datenbankentwicklung ein Kinderspiel. Wir könnten bei jeder Veröffentlichung einfach alles TROPFEN und dieses problematische Ä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 die 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.
Es heißt aus einem bestimmten Grund SQL Server Management Studio. Als eigenständiges Tool ist es unpraktisch, Ihre Entwicklungsbemühungen zu verwalten. if Sie werden anerkannte Best Practices befolgen.
Nur mit Skripten müssen Sie sowohl Objektdefinitionen (z. B. ein CREATE TABLE-Skript) als auch Skripts (z. B. ALTER TABLE) ändern UND hart daran arbeiten, sicherzustellen, dass sie synchron bleiben, um etablierte Methoden zur Quellcodeverwaltung auf Ihre Entwicklung sinnvoll anzuwenden.
Die Versionskette für Änderungen an einer Tabelle wird ziemlich schnell ziemlich dumm. 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:
ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)
Wenn die Live-Version dieser Datenbank Version 1 und unsere nächste Version Version 3 ist, ist das folgende Skript alles, was benötigt wird, aber stattdessen werden beide ALTER-Anweisungen ausgeführt.
ALTER TABLE dbo.Widget ADD Description VARCHAR(100)
Sprints von 5 Jahren und 4 Wochen summieren sich zu einigen unterhaltsamen Versionsskripten und erfordern zusätzliches Personalhandling, 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. Was es nicht einmal vorgibt, ist, einen Datenbankentwickler bei der (manchmal) sehr komplexen Aufgabe zu unterstützen, Änderungen zu verwalten.
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 nicht glauben, fragen Sie Eric Sink .
Dies ist definitiv ein Schritt in die richtige Richtung und nimmt einen Großteil des manuellen Aufwands für die Pflege von Skripten weg. Aber (und es ist ein großes, aber), normalerweise sind manuelle Schritte erforderlich.
Die beliebten Schema-Vergleichstools können vollständig automatisiert und in den Erstellungsprozess integriert werden. Nach meiner Erfahrung ist es jedoch üblicher, einen Vergleich manuell auszuführen, die resultierenden Skripte in Augenschein zu nehmen, in die Quellcodeverwaltung einzuchecken und dann manuell auszuführen, um sie bereitzustellen. Nicht gut.
Jedes Mal, wenn wir fehlbaren Menschen in den Prozess der Erstellung oder Bereitstellung einbezogen werden müssen, gehen wir Risiken ein und machen den Prozess nicht wiederholbar.
Wenn Sie und Ihr Team zu den wenigen gehören, die einen vollautomatischen Schemavergleich und eine vollautomatische Bereitstellung haben, haben wir nichts dagegen! Ihr seid am ehesten offen für die Vorteile, die VS2010 zu bieten hat:
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 nicht glauben, fragen Sie Joel Spolsky .
Die Frage, die @NickChammas gestellt hat, sucht nach Killer-Funktionen, die zeigen, warum VS2010 ein Game Changer für die Datenbankentwicklung ist. Ich glaube nicht, dass ich auf dieser Grundlage den Fall vertreten kann.
Vielleicht komisch, wo andere Fehler in diesem Tool sehen, sehe ich starke Gründe für die Annahme:
Wenn Sie der einzige DBA in einem Projekt sind und alle Änderungen an der Datenbank verwalten, muss diese Argumentation lächerlich klingen und an Absurdität grenzen. Wenn Sie jedoch der Meinung sind, dass @BrentOzar einen Punkt hat und eine der neuen Regeln lautet: Jeder ist der DBA , müssen Sie die Datenbankänderung so steuern, dass jeder Entwickler im Team damit arbeiten kann.
Die Übernahme von Datenbankprojekten kann für einige Entwickler eine mentale Veränderung ( alter Gewohnheiten, die schwer zu brechen sind ) oder zumindest eine Änderung des Prozesses oder der Arbeitsabläufe erfordern. Entwickler, die Datenbankanwendungen entwickelt haben, bei denen die Produktionsdatenbank die aktuelle Version der Datenbank darstellt, müssen einen auf Quellcode basierenden 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 "Eine Version der Wahrheit" 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 ihre "Eine Version der Wahrheit", wie sie sein sollte.
Wir sind zu dem grundlegenden Wandel gekommen, der notwendig ist, um den VS2010-Ansatz für die Datenbankentwicklung erfolgreich anzuwenden.
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 hier, 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 gebracht werden soll. Sie fragen sich möglicherweise: Wie wird dies für eine Datenbank bereitgestellt, die bereits die Kundentabelle enthält? Hier kommt die Deployment Engine ins Spiel. Wie bereits erwähnt, nimmt die Bereitstellungsengine die kompilierte Version Ihres Schemas und vergleicht sie mit einem Datenbankbereitstellungsziel. Die Differenzierungs-Engine erstellt die erforderlichen Skripts, um das Zielschema so zu aktualisieren, dass es mit der Version übereinstimmt, die Sie aus dem Projekt bereitstellen.
Ja, es gibt andere Tools, die einem ähnlichen Muster folgen, und für Projekte außerhalb der Einschränkungen, die ich meiner Antwort auferlegt habe, 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 mithalten.
@AndrewBickerton erwähnte in einem Kommentar, dass ich die ursprüngliche Frage nicht beantwortet habe, daher werde ich versuchen, zusammenzufassen: "Warum sollte ich Visual Studio 2010 über SSMS für meine Datenbankentwicklung verwenden?" Hier.
VS kann großartig erscheinen, wenn Sie SSMS nicht kennen oder Tools von Drittanbietern verwendet haben. Die Lücken in VS fallen auf, wenn Sie Red Gate-Tools für den Schemavergleich usw. verwenden. Und auch die kostenlosen SSMS-Plug-Ins.
Die Quellcodeverwaltung ist irreführend: Was sich in der Produktionsdatenbank befindet, ist Ihre Referenzkopie. Nicht das, was der Entwickler verwendet. Sehen
Ich verwende Visual Studio ausgiebig (also BIDS) für das SSRS-Berichtsdesign und SSIS-Pakete. Ich konnte es auch nicht sehr gut machen, wenn überhaupt, in Management Studio. Visual Studio ist eine viel vollständigere und integrierte Entwicklungsumgebung und lässt sich auch viel besser in Quellcodeverwaltungssysteme einbinden. Und das spiegelt sich alles im Preis wider!
Um ehrlich zu sein, geht meine Stimme direkt an SQL Server Management Studio für Datenbankdesign, -entwicklung und (offensichtlich) Verwaltung. Es ist einfach einfacher zu tippen:
create table newTable
(
someId int identity(1, 1) not null primary key clustered,
...... you get the idea
)
Klicken Sie dann an den richtigen Stellen. SSMS ist ein großartiges Layout und ein absoluter Knaller. Und ich bin von Natur aus ein .NET-Softwareentwickler. Aber wenn es um Datenbankdesign und -codierung geht, wähle ich 11 von 10 SSMS.
Es gibt keine bewährten Methoden, aber mit dem VS 2010-Datenbankprojekt und dem Quellcode-Controller (VSS 2010, Subversion usw.) können Sie Ihre Datenbank versionieren.
Ich empfehle, dass Sie Ihre Datenbank zuerst direkt in SSMS entwerfen. Nachdem Ihre Datenbank fast fertig ist, importieren Sie sie in ein VS 2010-Datenbankprojekt. Nach Abschluss des Imports müssen Sie Ihrem Datenbankprojekt immer ein neues Skript hinzufügen, um alle Änderungen zu verfolgen. Sie können die Vergleichsfunktion des Datenbankprojekts verwenden, um alle Änderungen vom Entwicklungsserver abzurufen und alle diese Skripts direkt in Ihr Projekt zu importieren. Sie müssen jetzt nur noch Ihre Änderung in Ihren Quellcode-Controller "festschreiben".
Mit dieser Methode können Sie eine versionierte Datenbank haben. Sie können die Version jeder Änderung erkennen und Ihre Änderungen rückgängig machen.
Dies ist nicht der einzige Vorteil. Mit dieser Art von Projekt können Sie alle Datenbanken mit Ihrem Projekt vergleichen, um die Änderungen zu skripten, und mit dem SQL PowerShell-Befehl Eingabeaufforderung können Sie alle Ihre Datenbanken mit demselben Skript aktualisieren: Dieses Skript ist ein XML-Schema Ihrer Datenbank. Es werden nur die erforderlichen Befehle zum Aktualisieren Ihrer Datenbanken ausgeführt. Sie haben auch die Möglichkeit, nit Test in Ihrer Datenbank zu erstellen. Ein weiterer guter Artikel für Datenbankprojekte ist verfügbar hier . Mit der Bereitstellungsfunktion können Sie Vor- und Nachskripte erstellen. Mit diesen Skripten können Sie eine Validierung durchführen oder Daten in Ihre Systemtabellen einfügen.
hier ist eine gute Schritt-für-Schritt-Anleitung für Datenbankprojekte.
Ich verwende SSMS häufiger als VS2010, da es bei der Installation von SQL Server vorhanden ist. Das ist wahrscheinlich das Wichtigste, warum SSMS meiner Meinung nach mehr als VS2010 verwendet wird.
Ich habe auch festgestellt, dass Anbieter wie Red-Gate Tools herausbringen, die in SSMS und nicht unbedingt in VS2010 integriert sind. Dies kann insofern positiv sein, als Sie damit SSMS verbessern können, wo Microsoft dies nicht getan hat. Ein Beispiel hierfür ist die SQL-Quellcodeverwaltung von Red-Gate, ein Add-On zu SSMS, mit dem Sie SSMS mit dem Quellcodeverwaltungssystem Ihres Unternehmens verbinden können, unabhängig davon, ob es sich um Visual Team Foundation handelt oder was Sie haben. VS2010 hat diese integrierte Funktion, aber im Vergleich zum Preis des Reg-Gate-Tools habe ich nur eine Menge Geld gespart, ohne VS2010 kaufen zu müssen.
Ich denke, insgesamt kommt es auf die Präferenz an, dass Sie mit dem arbeiten, in dem Sie sich wohl fühlen. Wenn Sie eine neue Person trainieren und sie auf VS2010 trainieren, wird dies zu ihrer Präferenz, weil sie wissen, wie sie damit umgehen können.
Wenn Sie mit SQL Server 2012 angefangen haben, haben Sie möglicherweise bemerkt, dass SSMS langsam aber sicher das Make-up von VS2010 erhält. Möglicherweise können Sie den Unterschied zwischen ihnen nicht erkennen.