Meine Firma verwendet ein Visual Studio-Datenbankprojekt zum Bereitstellen von Updates für unsere Datenbank. Soweit ich das beurteilen kann, bietet es Funktionen zum Vergleichen des Status des Projektschemas und einer Ziel-DB und zum Generieren von Code, um das Schema des Letzteren zu dem Ersteren zu aktualisieren. Es enthält außerdem ein vorbereitendes Skript und ein nachbereitendes Skript, aber nicht mehr.
Was fehlt, ist ein Konzept der Versionierung und / oder Bestellung. Wenn ich beispielsweise eine nicht nullfähige FK-Spalte zu einer Tabelle hinzufügen möchte, muss ich dies in zwei Schritten tun: Zuerst fügen Sie sie als nullfähige Spalte mit einem Post-Deployment-Skript hinzu, um die Zeilen so zu aktualisieren, dass sie sinnvolle Werte enthalten Zweitens: Machen Sie die Spalte nicht nullfähig. Dies muss in der richtigen Reihenfolge geschehen.
Soweit ich das beurteilen kann, gibt es keine Möglichkeit, diese sequenzielle Anordnung von Skripten vor und nach der Bereitstellung durch die Bereitstellung mit Visual Studio-Datenbankprojekten zu gewährleisten. Bin ich hier? Dies hat zwei Auswirkungen: erstens, dass Sie einer Tabelle nach ihrer Erstellung nicht wirklich eine nicht nullfähige FK-Spalte hinzufügen können, und zweitens, dass Ihre Skripts vor und nach der Bereitstellung immer weiter wachsen und wachsen und enthalten cruft von Jahren, weil sie beide jedes Mal ausgeführt werden die Datenbank bereitgestellt wird.
Gibt es eine Möglichkeit, Versionsupdates mit Visual Studio-Datenbankprojekten durchzuführen, und wenn nicht, gibt es einen Projekttyp, der diese Versionierung zulässt?
Zuerst haben Sie dies mit visual studio 2012 getaggt - wenn Sie diese Version verwenden, müssen Sie auf Version 2013 oder 2015 upgraden und die neueste Version von SSDT erhalten, da die Releases alle drei Monate mit neuen Funktionen und Korrekturen veröffentlicht werden es lohnt sich, eine neuere Version zu bekommen - die Bits, über die ich unten spreche, sind das aktuelle Verhalten, ich weiß nicht, ob das alles in der originalen SSDT in Visual Studio 2012 verfügbar war.
Es gibt ein paar Dinge zu sagen, erstens können Sie geordnete Bereitstellungen erzwingen, indem Sie das / p: BlockWhenDriftDetected in Verbindung mit der Registrierung der Datenbank als Datenebenenanwendung (/ p: RegisterDataTierApplication) verwenden. Dies würde Ihnen erlauben, dies zu tun:
Es würde Sie davon abhalten, dacpac 2 zu implementieren, bevor dacpac 1 bereitgestellt wurde, aber es ist nicht ideal, denn wenn Sie dacpac 3 vor dem Deployment von dacpac 2 erstellt hätten, könnten Sie es nicht bereitstellen, ohne dacpac 3 neu zu erstellen 't ideal.
Wenn Sie mit Änderungen für eine Datenbank (irgendwelche rdbms, nicht nur SQL-Server) zu tun haben, gibt es manchmal Fälle, in denen wir Änderungen in Phasen freigeben müssen und für mich eher ein Prozessproblem als ein technisches Problem ist. Was ich mache ist:
Einige Dinge zu beachten:
Wenn Sie diesen Prozess befolgen und sich nicht auf den Versionierungstyp der Richtlinie verlassen, müssen Sie sich keine Gedanken darüber machen, in welcher Reihenfolge Sie dacpacs bereitstellen. Wenn ein Skript wichtig ist, lassen Sie es im post-deploy-Skript und überprüfen Sie, ob das Skript dies erfordert machen Sie eine Arbeit, bevor Sie es tun. Wenn Ihre Skripte zu groß werden, können Sie Folgendes verwenden: • sqlcmd importiert sie in verschiedene Dateien. Ich habe auch von Leuten gehört, die gespeicherte Deployment-Prozeduren verwenden und diese von Post-Deploy-Skripten aufrufen.
Ich bevorzuge einen Prozess, bei dem Sie nur die neueste (oder spezifische Version) eines dacpac bereitstellen, da Sie immer auf diese Version bereitstellen können, egal ob Sie zu einem späteren Build oder zu einem früheren Build zurückkehren.
Schließlich können Sie mit Ihrem Beispiel für das Hinzufügen einer nicht nullbaren fk-Spalte dies mit einer einzigen Bereitstellung eines dacpac tun. Um dies zu tun, würdest du:
Was passiert, wenn das Deployment-Skript generiert wird, erhalten Sie ein Skript, das wie folgt aussieht:
Die / p: Parameter Dinge, die ich erwähnt habe, sind Argumente, die Sie an sqlpackage.exe übergeben. Wenn Sie das nicht verwenden, aber eine andere Art der Bereitstellung verwenden, können Sie diese normalerweise als Parameter übergeben, wenn Sie mir mitteilen, wie Sie das Deployment durchführen, wenn Sie nicht weiterkommen und ich Ihnen helfen kann. Für eine Beschreibung der Argumente siehe Ссылка (sqlpackage.exe Befehlszeilensyntax).
>Lassen Sie mich wissen, wenn Sie Fragen haben, es gibt einige zusätzliche Dinge, über die Sie nachdenken sollten, aber das Einchecken Ihrer Schemadefinition und automatisch generierte Bereitstellungsskripts reduziert die Arbeit, um Änderungen drastisch zu implementieren und bedeutet, dass Sie sich auf etwas Nützlicheres konzentrieren können - Schreibeinheit Tests für eins:).
Ed
Tags und Links sql-server database visual-studio-2012 ssdt