Wir haben ein mittelgroßes SSDT-Projekt (~ 100 Tabellen), das für Dutzende verschiedener Datenbankinstanzen bereitgestellt wird. Als Teil unseres Build-Prozesses generieren wir eine .dacpac-Datei. Wenn wir dann bereit sind, eine Datenbank zu aktualisieren, generieren wir ein Publish-Skript und führen es gegen die Datenbank aus. Einige db-Instanzen werden zu unterschiedlichen Zeitpunkten aktualisiert, daher ist es wichtig, dass wir einen strukturierten Prozess für diese Upgrades und Versionierungen haben.
Der größte Teil des generierten Migrationsskripts besteht darin, Prozeduren, Funktionen, Indizes und alle strukturellen Änderungen sowie einige in einem Post-Deployment-Skript enthaltene Datenskripte zu löschen und (neu) zu erstellen. Es sind diese zwei datenbezogenen Elemente, von denen ich gerne wissen möchte, wie man sie am besten innerhalb des Projekts strukturiert:
Benutzerdefinierte Datenmigrationen zwischen den Versionen erforderlich
Statische Daten oder Referenzdaten
Benutzerdefinierte Datenmigrationen zwischen Versionen erforderlich
Manchmal möchten wir im Rahmen eines Upgrades eine einmalige Datenmigration durchführen, und ich bin mir nicht sicher, wie dies am besten in unser SSDT-Projekt integriert werden kann. Zum Beispiel habe ich kürzlich eine neue Bitspalte dbo.Charge.HasComments hinzugefügt, um (redundante) abgeleitete Daten basierend auf einer anderen Tabelle zu enthalten und wird über Trigger synchron gehalten. Eine lästige aber notwendige Leistungsverbesserung (nur nach sorgfältiger Überlegung und Messung hinzugefügt). Als Teil des Upgrades enthält das SSDT-generierte Publish-Skript die notwendigen ALTER TABLE - und CREATE TRIGGER -Anweisungen, aber ich möchte diese Spalte auch basierend auf Daten in einer anderen Tabelle aktualisieren:
Was ist der beste Weg, dieses Datenmigrations-Skript in mein SSDT-Projekt aufzunehmen?
Derzeit befinden sich diese Migrationsarten in einer separaten Datei, die im Post-Deployment-Skript enthalten ist. Daher sieht mein Post-Deployment-Skript folgendermaßen aus:
%Vor%Ist dies der richtige Weg, oder gibt es eine Möglichkeit, SSDT und seine Versionsverfolgung besser zu integrieren, so dass diese Skripts nicht einmal ausgeführt werden, wenn der SSDT-Publish für eine Datenbank ausgeführt wird, die bereits eine neuere Version. Ich könnte meinen eigenen Tisch haben, um zu verfolgen, welche Migrationen durchgeführt wurden, aber ich würde es vorziehen, nicht zu rollen, wenn es eine Standardmethode dafür gibt.
Statische Daten oder Referenzdaten
Einige der Datenbanktabellen enthalten, was wir statische oder Referenzdaten nennen, z. Liste der möglichen Zeitzonen, Einstellungstypen, Währungen, verschiedene "Typ" -Tabellen usw. Derzeit füllen wir diese mit einem separaten Skript für jede Tabelle, die als Teil des Post-Deployment-Skripts ausgeführt wird. Jedes statische Datenskript fügt alle 'korrekten' statischen Daten in eine Tabellenvariable ein und fügt dann die statische Datentabelle bei Bedarf ein / aktualisiert / löscht sie. Abhängig von der Tabelle kann es sinnvoll sein, nur existierende Datensätze einzufügen oder nur einzufügen und zu löschen, nicht aber zu aktualisieren. Jedes Skript sieht also ungefähr so aus:
%Vor%und dann hat mein Post-Deployment-Skript einen Abschnitt wie folgt:
%Vor%Gibt es eine bessere oder konventionellere Möglichkeit, solche statischen Datenskripts als Teil eines SSDT-Projekts zu strukturieren?
Um nachzuverfolgen, ob das Feld bereits initialisiert wurde oder nicht, versuchen Sie, eine erweiterte Eigenschaft hinzuzufügen, wenn die Initialisierung ausgeführt wird (es kann auch verwendet werden, um die Notwendigkeit der Initialisierung zu bestimmen):
Um die erweiterte Eigenschaft hinzuzufügen:
%Vor%Um nach der erweiterten Eigenschaft zu suchen:
%Vor%Verwenden Sie für Referenzdaten einen MERGE. Es ist viel sauberer als die dreifache Menge von Abfragen, die Sie verwenden.
%Vor%Tags und Links sql-server data-migration ssdt