SQL Source Control lässt sich in SSMS einbinden und verbindet Ihre Datenbanken mit Ihrem Versionskontrollsystem. So können Sie Ihre Datenbankschemata versionskontrollieren und anschließend mithilfe der bewährten Redgate-Vergleichsmaschine SQL Compare bereitstellen.
Das neueste Release (das diese Woche ausgeliefert wird!) bietet eine verbesserte Version der Migrationsskripte, mit denen Sie Ihr eigenes SQL schreiben können, um das von SQL Compare generierte Deployment-Skript zu überschreiben, so dass Ihre Mitarbeiter die neuesten Änderungen aus der Versionskontrolle abrufen können, ohne das Risiko eines Datenverlusts einzugehen. Sie können mehr darüber erfahren, was wir getan haben und warum, in einem anderen Blogpost von mir.
Aber hier möchte ich Ihnen anhand eines häufigen Szenarios erklären, wie es funktioniert.
Wie Sie Datenverluste beim Umbenennen einer Tabelle vermeiden
Gängige Aufgaben, die davon betroffen sein können, sind das Teilen oder Zusammenführen von Spalten und Tabellen, das Hinzufügen einer NOT NULL-Beschränkung zu einer Spalte, das Ändern des Datentyps oder der Größe einer Spalte und das Umbenennen einer Tabelle.
In dem Fall, dass Sie eine Tabelle in Ihrer Entwicklungsdatenbank umbenennen, würde SQL Source Control diese Änderung als DROP und CREATE interpretieren. Wenn ein anderes Mitglied Ihres Teams die Registerkarte „Zuletzt abrufen“ verwendet, um diese Änderungen zu erhalten, gehen Daten in der Zieltabelle verloren.
Um diesen Datenverlust zu vermeiden, können Sie ein Migrationsskript schreiben, um die Tabelle mithilfe der gespeicherten Prozedur sp_rename umzubenennen. Dieses Skript ersetzt die DROP- und CREATE-Anweisungen, die die SQL Compare-Engine sonst für diese Änderung generieren würde.
Nachdem Sie Ihre Tabelle umbenannt haben (in diesem Fall von „Benutzer“ in „Kunden“), besteht der nächste Schritt darin, die Änderungen über die Registerkarte „Änderungen festschreiben“ in der SQL-Quellsteuerung an Ihr Quellsteuerungssystem zu übergeben. SQL Source Control warnt Sie, dass durch das Commit der Änderung ein Datenverlust entstehen kann und schlägt Ihnen vor, ein Migrationsskript zu schreiben.
Auf der Registerkarte „Migrationen“ und unter „Uncommitted Schemaänderungen ersetzen“ würden Sie dann mit Hilfe der Checkboxen die relevanten Schemaänderungen auswählen.
In diesem Beispiel ersetzen Sie unbestätigte Schemaänderungen, weil Sie die Tabelle bereits umbenannt, aber noch nicht bestätigt haben. Die Umbenennung wird von SQL Compare als DROP und CREATE interpretiert und das Migrationsskript ersetzt diese Änderungen im Deployment-Skript (die andere Möglichkeit wäre, mit einem leeren Skript zu beginnen, was Sie tun würden, wenn Sie Ihr Schema bereits für die Migration vorbereitet und die Änderungen festgeschrieben hätten).
Indem Sie auf Skript generieren klicken, generiert SQL Source Control ein Migrationsskript basierend auf den nicht festgeschriebenen Änderungen und Sie können dann die automatisch generierten DROP- und CREATE-Anweisungen ersetzen.
In diesem Fall würden wir folgendes SQL verwenden:
EXEC sp_rename 'dbo.users', 'customers'GO CREATE SYNONYM dbo.users FOR customersGO
Das Synonym für die Tabelle „Kunden“ hier vermeidet Probleme, wenn die Tabelle mit dem alten Namen referenziert wird.
Dann können Sie speichern und schließen und dieses Migrationsskript ersetzt nun die vorgenommenen Änderungen.
Zurück in der Registerkarte Commit sehen Sie das Migrationsskript mit den zugehörigen Schemaänderungen darunter eingebettet. Nun müssen Sie nur noch das neue Migrationsskript auswählen, einen Kommentar eingeben und die Änderungen festschreiben.
Sie sind nun bereit, die Änderungen zu verteilen. Wenn Sie SQL Compare verwenden, wird das Migrationsskript während der Bereitstellung automatisch ausgeführt, wobei die gespeicherte Prozedur sp_rename anstelle der ursprünglich von der SQL Compare-Engine generierten Anweisungen DROP und CREATE verwendet wird.