Wir entscheiden uns dafür, alles zu skripten, und dazu gehören alle gespeicherten Prozeduren und Schemaänderungen. Es sind keine wysiwyg-Tools und keine ausgefallenen 'Sync'-Programme erforderlich.
Schemaänderungen sind einfach, Sie müssen lediglich eine einzige Datei für diese Version erstellen und verwalten, einschließlich aller Schema- und Datenänderungen. Dies wird Ihr Konvertierungsskript von Version x zu x+1. Sie können es dann mit einem Produktions-Backup ausführen und dieses in Ihren „täglichen Build“ integrieren, um zu überprüfen, ob es fehlerfrei funktioniert. Beachten Sie, dass es wichtig ist, bereits geschriebene Schema-/Datenlade-SQL nicht zu ändern oder zu löschen, da Sie am Ende jede später geschriebene SQL beschädigen können.
-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO
-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO
Für gespeicherte Prozeduren wählen wir eine einzelne Datei pro Sproc, und sie verwendet das Drop/Create-Formular. Alle gespeicherten Prozeduren werden bei der Bereitstellung neu erstellt. Der Nachteil ist, dass Änderungen, die außerhalb der Quellcodeverwaltung vorgenommen wurden, verloren gehen. Gleichzeitig gilt das für jeden Code, aber Ihr DBA muss sich dessen bewusst sein. Dies hält wirklich Leute außerhalb des Teams davon ab, mit Ihren gespeicherten Prozeduren herumzuspielen, da ihre Änderungen bei einem Upgrade verloren gehen.
Bei Verwendung von Sql Server sieht die Syntax folgendermaßen aus:
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO
CREATE PROCEDURE [usp_MyProc]
(
@UserID INT
)
AS
SET NOCOUNT ON
-- stored procedure logic.
SET NOCOUNT OFF
GO
Das einzige, was noch zu tun bleibt, ist ein Dienstprogramm zu schreiben, das alle einzelnen Dateien zusammenträgt und eine neue Datei mit dem gesamten Satz von Updates (als ein einziges Skript) erstellt. Tun Sie dies, indem Sie zuerst die Schemaänderungen hinzufügen, dann die Verzeichnisstruktur wiederholen und alle gespeicherten Prozedurdateien einschließen.
Als Vorteil, alles zu skripten, werden Sie viel besser im Lesen und Schreiben von SQL. Sie können diesen gesamten Prozess auch aufwändiger gestalten, aber dies ist das grundlegende Format, wie Sie alle SQL-Quelltexte ohne spezielle Software steuern können.
Nachtrag:Rick hat Recht, dass Sie mit DROP/CREATE Berechtigungen für gespeicherte Prozeduren verlieren, sodass Sie möglicherweise ein anderes Skript schreiben müssen, um bestimmte Berechtigungen wieder zu aktivieren. Dieses Berechtigungsskript wird als letztes ausgeführt. Unsere Erfahrung hat mehr Probleme mit der ALTER- als der DROP/CREATE-Semantik ergeben. YMMV
