Source-Control-tools für Visual Studio 2010 und SQL Server 2008-Skripte und Datenbank-updates?
Sind wir derzeit mit Visual Studio 2010 und SQL Server 2008 R2 - Entwicklung intranet ASP.NET Anwendungen, die verwenden (mehrere) SQL-Server-Datenbanken.
Wir haben die Speicherung von Skripten (für die Datenbanken) für SQL-Server-source-control, getrennt von tools wie SQL Server Management Studio (SSMS) oder Visual Studio. Das heißt, wir haben eine Sammlung von text-Dateien mit den Skripts für Tabellen, gespeicherte Prozeduren etc.; und wir prüfen diese in-und out-of-source-control direkt vor Sie zu aktualisieren (wie im Management Studio) und überprüfen Sie wieder an (und dann über die Scripte, die in SSMS um die Datenbank zu aktualisieren).
Würden wir jetzt gerne bewegen, um einen stärker integrierten Ansatz.
Habe ich gelesen, einige der Fragen/Antworten bei StackOverflow auf die source-control im Zusammenhang mit SQL Server (einige von Ihnen zurückgehend bis fast Anfang der StackOverflow), aber keine gefunden haben hervorragende Lösungen. Auch einige der Einträge, die ein Datum vor Visual Studio 2010, SQL Server 2008 oder einige der tools sind nun verfügbar.
Ich habe auch andere Beiträge gelesen zu diesem Thema, wie Troy Hunt ' s Artikel (ein Beispiel ist: http://www.troyhunt.com/2011/02/automated-database-releases-with.html) und K. Scott Allen Artikeln (zum Beispiel: http://odetocode.com/blogs/scott/archive/2008/02/02/versioning-databases-views-stored-procedures-and-the-like.aspx).
SQL Server Management Studio hat das Konzept einer "Datenbank-Projekt", aber dies ist offenbar eine als veraltet markierte Funktion und wird nicht empfohlen für neue Entwicklung.
Ansätze, die wir erwägen im moment sind:
(1) Erstellen Sie eine SQL Server 2008-Datenbank-Projekt in Visual Studio 2010 und verbinden Sie diesen mit source control (TFS oder VSS, zum Beispiel). [Dieser option können erfordert Premium oder Ultimate oder Team Database Edition von Visual Studio.]
Dieser Ansatz betrachtet das Skript zu "master" und die Datenbank wird angelegt/aktualisiert, dass das synchronisieren mit dem Skript version.
Wünschenswerte Merkmale dieses Ansatzes sind: die Globale Suche, suchen/ersetzen, refactoring, Warnungen über fehlende Indizes oder ungültig referenzierte Elemente, etc.
Die Nachteile sind: kein GUI-designer für Tabellen und andere Elemente können leicht Daten verloren gehen, mit einigen änderungen zu Spalten (da die "alter" - Skript löscht die Spalte und neu erstellt), fehlende "Dokument formatieren" - Befehl (verfügbar in Visual Studio für web-Projekte, aber nicht für die Datenbank-Projekte).
(2) Red gate SQL Source Control - (und SQL-Compare), die in SQL Server Management Studio.
Dieser Ansatz im wesentlichen der Auffassung der Datenbank "master", und die Skripte sind aktualisiert, basierend auf änderungen am Datenbank-design. In vielerlei Hinsicht ist dies einer genaueren übereinstimmung der Weise, dass sich viele kleinere Entwicklungsteams arbeiten.
Der große Vorteil dieses Ansatzes ist, dass Sie zur Verfügung haben alle SSMS tools und Designer.
Die Nachteile sind, dass es weniger design-Integrität prüfen, ohne suchen/ersetzen oder die Globale Suche (ohne das installieren von anderen add-ons), und die generierten Skripts mit SQL Source Control syntaktisch unterscheidet sich von den Skripts erzeugten nativ vom SSMS oder Visual Studio (das Ergebnis ist das gleiche).
=====
Haben Sie Vorschläge für alternative Ansätze gibt es bestimmte tools oder Dienstprogramme, die Sie verwenden/bevorzugen Sie für die Integration von Quellcodeverwaltung für Datenbanken von SQL Server in SQL Server Management Studio oder Visual Studio 2010, und wie über die Ansätze für die Aktualisierung/Synchronisierung sowohl die Entwicklung und Produktion von Datenbanken mit änderungen?
Habe ich auch angeschaut, ein paar andere software-utilities/tools für diesen Zweck (einige von diesen wurden schon in anderen StackOverflow Themen):
SQL Examiner (eine Möglichkeit, obwohl es ein komplett separates tool; nicht integriert in SSMS oder Visual Studio)
LiquiBase (Apache/Java, kein .Noch NET)
NeXtep (keine SQL-Server-Unterstützung noch)
DBSourceTools (nicht integriert genug noch)
Du musst angemeldet sein, um einen Kommentar abzugeben.
Meine Org wurde mit beiden für zwei verschiedene Projekte, und ich habe sehr teilweise auf die tools von RedGate. Wie Sie erwähnen, um die volle Funktionalität benötigen Sie die gesamte toolset von RedGate, aber Sie bekommen eine Menge extras mit, dass als gut (einschließlich refactoring, oder global suchen/ersetzen). Für die Synchronisierung von DEV auf TEST - /QS - /PROD-Umgebungen benutze ich Ihre Produkte Vergleichen zu bauen Sätze von Skripts (die in der Regel erfordern weitere überprüfung). Ich weiß nicht wirklich Vertrauen-tool, aktualisieren Sie ein schema verwenden, es sei denn, ich bereit bin, zu schnell wiederherstellen.
Im Gegensatz dazu fand ich die MS-tools zu kompliziert, das machte Sie etwas unflexibel. Wir fanden uns in einer Gurke, wenn wir hatten einige änderungen in der DB, die benötigt werden synchronisiert, um das Projekt, aber änderungen im Projekt, die würde nicht zulassen, dass es gebaut werden, ohne die änderungen aus der DB... es endete in einer ganzen catch-22 Szenario, das erforderte VIEL manuelle Bearbeitung (und führte zu einer Prüfung und den Erwerb der RedGate-tools).
Einen zusätzlichen Faktor oder Kriterien, die Sie betrachten wünschen können, ist, wo Sie und Ihr team sind die meisten komfortabel schreiben Ihre scripts \ gespeicherte Prozeduren, etc.
Haben wir ausgewertet Visual Studio Team Database Edition (oder was es auch immer ist derzeit aufgerufen, in diesen Tagen) in der Vergangenheit und kam zu dem bedauerlichen Schluss, dass wir waren einfach nicht bequem und glücklich das schreiben von SQL in Visual Studio. Wir sind sehr viel produktiver als ein team, das schreiben von SQL mithilfe von SSMS. Natürlich könnte das Gegenteil wahr zu sein.
Sind wir auch in der Mitte der Auswertung von Red-Gate ' s SQL Source Control tool. Das größte plus für uns ist, dass es funktioniert innerhalb von SSMS und ist relativ reibungslos. Aus welchem Grund auch immer, Ihre Modell-maps ein bisschen besser, wie wir dazu neigen, SQL-Entwicklung arbeiten.
In Bezug auf die Bereitstellung, die beiden Produkte scheinen neigen etwas mehr in Richtung Entwicklung zu arbeiten, wo Bereitstellung von änderungen an einer Datenbank, die auf Ihren Servern. Aus ISV-Sicht dies macht es ein bisschen schwieriger zu generieren deployment-Skripte ausgeführt werden, die auf eine Datenbank außerhalb von Euch Umgebung (z.B. Datenbank, die auf einem client-server).
Deshalb, ich persönlich mag den Ansatz, die Microsoft ergriffen hat, wo Sie können erstellen eine schema-Datei, die beschreibt das schema der Datenbank. Ich bin wohl etwas verlassen aus, aber ich erinnere mich daran, dass diese schema-Datei ist, was verwendet wird zum generieren der Skripts zum aktualisieren einer Ziel-Datenbank. Die Schönheit dieser Lösung ist, dass die Skripts ändern, könnte unterschiedlich sein, je nach Zustand der Ziel-Datenbank.
Leider, wenn Sie nicht haben, "DBPro" zur Verfügung (denken Sie noch einmal an client-Seite für einen moment) bist du Links mit VSDBCMD zum generieren der Skripts ändern, die aus der schema-Datei. Während dies funktioniert, es wäre schön, wenn Microsoft ausgesetzt, die eine API für VSDBCMD so könnte man erstellen Sie eine GUI, um es einfacher für nicht-Entwickler-Typen auszuführen, anstatt zu verwenden, ein Kommandozeilen-tool.
Es ist schwer vorstellbar, dass VS Team Database Edition nicht gewinnen zusätzliche features in der Zukunft, so ist das Wetten auf MS ist wohl nicht wirklich ein Glücksspiel, natürlich vorausgesetzt, Sie Leben können mit den jetzigen Schwächen des Tools.
Sie nicht integrieren-source-control in die Datenbank als solche.
Es ist nicht Datei-basiert. Ihre Datenbank besteht aus Tabellen, code, Daten, Indizes, Statistiken, Sicherheit etc: diese Leben alle in system-Tabellen.
Eher die copy+paste, siehe meine vorherigen Antworten...
Folgen wir Martin Fowler ' s "Evolutionary Database Design" mehr oder weniger