DACPAC-Paket mit komplexen Änderungen

Ich bin auf der Suche nach DACPACs für unsere Datenbankänderungen, aber ich bin ein wenig ratlos, was zu tun ist, wenn es um komplexere Datenbankupdates geht. Um zu veranschaulichen, was ich meine, lassen Sie mich ein einfaches Beispiel verwenden, das dasselbe Problem hat.DACPAC-Paket mit komplexen Änderungen

Angenommen, ich besitze eine Customer-Tabelle, die gerade aktiv ist, und möchte eine neue CustomerType-Tabelle mit einem Fremdschlüssel vom Kunden zum CustomerType hinzufügen. Die neue Spalte in Customer sollte erforderlich sein (nicht Nullable), sollte aber keinen Standardwert haben.

Ich möchte eine beliebige Formel verwenden, um den ursprünglichen Typ für die bestehenden Kunden beim Aktualisieren einzurichten. Wie würde ich dies mit einem DACPAC erreichen?

Der DACPAC wird nur wissen, dass es eine neue Spalte gibt und versuchen, sie der Tabelle Customer hinzuzufügen, die natürlich fehlschlägt, weil sie benötigt wird. Das Festlegen eines Standardwerts ist unerwünscht, da NULL-Werte zulässig sind.

Da der DACPAC für die Aktualisierung von jedem Status auf den neuesten verwendet werden kann, sehe ich nicht, welche Art von Konfiguration oder Pre/Post-Scripts ich einrichten sollte, damit dies funktioniert.

Verschiedene Suchanfragen haben einen enttäuschenden Mangel an nützlichen Ergebnissen :(

Ich hoffe, es ist jemand hier, die helfen kann. Vielen Dank im Voraus.

Quelle

2016-08-08 Robba

Die Antwort ein wenig variieren, je nachdem wie du bist Es ist ein häufiger Fall, dass der dacpac eine Reihe von T-SQL-Update-Skripten ersetzt, die nacheinander ausgeführt werden, um ein Datenbankschema von einer Version auf die nächste zu aktualisieren. In diesem Fall haben Sie die Wahl eine Dacpac-Datei für jede Schema-Version Ihrer Datenbank und um eine Datenbank zu aktualisieren, würden Sie planen, die Dacpacs der Reihe nach zu veröffentlichen, um eine Datenbank auf die neueste Version zu aktualisieren

In diesem Fall ist es möglich, ein Post-Deployment-Skript zu verwenden, um das Schema entsprechend zu korrigieren. Für Ihr Beispielszenario können Sie die Datenbank im Datenbankprojekt mit der neuen als NULL angegebenen Spalte und ohne die FK-Beziehung mit der neuen Tabelle modellieren. Anschließend können Sie in einem Post-Deployment-Skript das T-SQL erstellen, das zum Ausführen einer UPDATE-Anweisung zum Füllen der neuen Tabelle und der neuen Spalte erforderlich ist, eine ALTER-Anweisung zum Ändern des Spaltentyps von NULL in NOT NULL und schließlich zum Hinzufügen der Fremdschlüsselbeziehung.

Anschließend können Sie das Post-Deployment-Skript entfernen und die neue Spalte und Tabelle mit dem richtigen Spaltentyp und der richtigen FK-Beziehung modellieren.

Quelle

2016-08-08 19:15:30

Nun, ich würde gerne in der Lage sein, den DACPAC als einen Endzustand zu verwenden, wie er beabsichtigt ist, aber mit einer gewissen Kontrolle über die Übergänge zwischen Zuständen. Wenn Sie ein Post-Deployment-Skript verwenden, das die Nullbarkeit der Spalte ändert, bedeutet dies, dass jeder Vergleich zwischen dem DACPAC und einer vollständig aktuellen Datenbank noch Änderungen nach sich zieht (nämlich die Spalte, die nicht nullfähig ist, aber nach dem 'final Staat 'das ist in der DACPAC) – Robba

Einverstanden, es ist unvollkommen. Wir (das SSDT-Team) möchten diese Szenarios verbessern, haben jedoch andere Verbesserungen priorisiert (z. B. das Hinzufügen einer ignorierten Spaltenreihenfolge). –

Ich dachte, die fk wäre deaktiviert, bis nach dem Post-Deployment-Skript ausgeführt wurde, so dass Sie die Daten in der Post-Bereitstellung einrichten konnten (machen Sie es re-runnable/idempotent wie where new_col = null) und die Spalte würde ohne die Einschränkung hinzugefügt werden, Die Post-Bereitstellung wird ausgeführt und aktualisiert die Spalte und schließlich werden die Einschränkungen am Ende des Upgrades aktiviert. –

Antwort

Verwandte Themen