Frage Wer nutzt "Datenbankprojekte" in Visual Studio?


Ich habe es vor kurzem versucht (SQL 2008 Version) und ich finde sie ganz okay. Nun, das einzige Problem ist, dass der Assistent nicht intelligent genug ist, um die Datenbankstruktur zu aktualisieren, ohne zuerst alle Daten zu löschen. Werden diese Projekte deshalb in der Praxis nicht genutzt?

Ich habe noch nie jemanden gesehen, der sie benutzt oder jemals erwähnt hat. Auch in Blogs und Foren ist nichts zu sehen, es sei denn, Sie suchen explizit danach.

Was stimmt mit denen nicht?


17
2018-03-16 14:13


Ursprung


Antworten:


Ich verwende das Datenbankprojekt, das Teil der Visual Studio Database Edition ist. Dies ist ein großartiges Werkzeug. Grundsätzlich definieren Sie das gesamte Schema in Create-Skripten, die dann in die Quellcodeverwaltung eingecheckt werden. Es hat dann Werkzeuge eingebaut, um Differenz-Skripte zu erzeugen, die übrigens die Daten nicht löschen.

Es verfügt außerdem über Datenvergleichstools, mit denen Sie Daten zwischen Datenbanken vergleichen und das Skript generieren können, um die Datenbanken gleich zu machen.

Die jüngste DDR-Veröffentlichung hat einige interessante Features hinzugefügt. So, dass es sich anhört, wenn Sie ihre integrierte Bereitstellungsmethode verwenden, können Sie ein Bereitstellungspaket generieren, das bei der Ausführung die Zieldatenbank analysiert und nur die Unterschiede anwendet.

Wenn Sie Team Studio - Team Suite oder Development Edition haben, können Sie die Datenbank-Edition verwenden.

Probieren Sie es aus und ist eine großartige Entwicklung in der Datenbankentwicklung


9
2018-03-16 14:16



Wie Glennular benutzen wir sie zur Versionskontrolle unseres Schemas und unserer Prozeduren.

Obwohl wir eine ziemlich fortschrittliche Versionssteuerungsstruktur (CI, automatische Bereitstellungen für Entwickler, Single-Click-Bereitstellungen für die Stage und Prod) haben; Wir berücksichtigen keines der DB-Projekte in dieser Struktur. Wir trauen es noch nicht.

AKTUALISIEREN: (für draußen im Raum)

Wir haben separate TFS-Projekte für funktionale Bereiche des Unternehmens (Vertrieb, Marketing, etc.). In jedem TFS-Projekt haben wir einen Hauptordner und einen Produktionsordner. Wir haben auch ein TFS-Projekt, das die Datenbankprojekte enthält, und ein weiteres, das allgemeine Assemblys / Visual Studio-Projekte enthält.

Nach der Veröffentlichung verzweigen wir von Main zu Production. Wir haben keinen Staging-Zweig, da wir uns zu schnell bewegen, um damit fertig zu werden. Richtig oder falsch, unsere Produktivität wird zum Teil durch die Anzahl der Releases auf Produktionsebene gemessen, die wir pro Woche durchführen; Bugfixes, neue Features, etc.

CI wird im Hauptzweig so eingerichtet, dass bei jedem Einchecken der Buildserver in unseren DEV-Umgebungen bereitgestellt wird. Unit- und Web-Tests werden dann ausgeführt und die Build-Qualität wird automatisch auf "Entwicklung" gesetzt, wenn sie erfolgreich abgeschlossen wurde. Wenn jemand die Build-Qualität in "In Staging" ändert, werden alle vorherigen "In Staging" -Builds auf "Rejected" gesetzt und bewirkt, dass Build auf unsere Staging-Server übertragen wird, während die Konfigurationsdateien auf die richtigen Server verweisen. (Ich habe dazu TFS Deployer und PowerShell-Skripte verwendet).

QA testet unsere Staging-Server. Sobald sie zufrieden sind, ändert das Produktionsteam die Build Quality in "Production". Dadurch wird der Build an einen Produktionsbereich gesendet, der dann manuell an den richtigen Speicherort kopiert wird. Sobald die Produktion abgeschlossen ist, benachrichtigt die Produktion die Entwicklung, die diese Version in den Produktionsordner verzweigt. QA wird auch benachrichtigt, wer dann eine Batterie von Produktionstests durchführt, um zu überprüfen, ob alles tatsächlich wie erwartet funktioniert.

Wir haben Berichte eingerichtet, die uns zeigen, welche Änderungen zwischen den Produktionsfreigaben bestehen, so dass wir jeden Check-In kennen, der bereitgestellt wird. Dies verhindert, dass Unbekannte auftauchen, wie beispielsweise ein Datenbankwechsel oder ein anderer Code, der möglicherweise bricht.

Darüber hinaus verfolgen unsere BA Workitems über Team System Web Access und wissen, wann diese Artikel in Produktion sind.

Obwohl unsere Datenbankadministratoren Database Edition (GDR) verwenden, waren sie nicht von der Kontrollstufe für automatische Bereitstellungen beeindruckt. Ich hoffe, dass Rosario eine bessere Kontrolle über die Einsatzmöglichkeiten in der Produktlinie bietet. Aber bis dahin haben wir TFS Deployer und Powershell.


8
2018-03-16 14:40



Wir benutzen sie. Wir behalten alle unsere Schemas, Skripte und Stored Procedures. Der Hauptzweck ist, dass wir das Projekt mit einem SourceSafe oder SVN verbinden können.

Es ist eine einfache Möglichkeit, Ihre SQL-Skript-Version kontrolliert zu halten.

Es ist ein wenig eigenartig, versuchen einige SQL-Tests in VS, aber Sie finden Möglichkeiten, um es herum.

Aktualisieren

Wir haben es tatsächlich in unsere Deployment-Skripte eingebaut, unser Deployment-Tool, führt das DB-Projekt durch (mit Ausnahme von markierten Ordnern) und führt das gesamte Skript aus. Wir haben gerade ein schnelles Tool für das Projekt erstellt. Wenn jemand andere Lösungen zum Bereitstellen des DB-Projekts hat, wäre das hilfreich.


5
2018-03-16 14:18



Wir verwenden das Datenbankprojekt zur Versionskontrolle für unsere SQL-Skripte. Wir verwenden auch gerne die Visual Studio-Umgebung, um das SQL zu bearbeiten. Es ist ein wenig einfacher für einige unserer neueren Entwickler als Abfrageanalysator zu verwenden.


1
2018-03-16 14:41



Ich habe sie für ein paar bezahlte Projekte verwendet und finde es ein großartiges Werkzeug. Das ist gesagt, ich habe einige Probleme gesehen.

  1. Wenn die .dat-Datei in Ihrem Db-Projektordner mit der temporären Instanz der Datenbank nicht mehr synchron ist, führt der Schemavergleich zu ungenauen Ergebnissen. Nicht sicher, wie dies passiert, überprüfen Sie Schema vergleicht sorgfältig und wegblasen Ihre .dat-Datei (nach dem Schließen der Lösung), wenn die Dinge scheinen falsch.

  2. Wenn Sie mehr als 20 Datenbanken haben und sie sich gegenseitig referenzieren und zirkuläre Referenzen verwenden, wird es weh tun. Ich habe nicht herausgefunden, wie man es auf dieses Szenario skalieren kann. DDR 2 scheint vielversprechend zu sein.


1
2018-05-27 20:31