Der beste Weg, um die Tabellen nach Abschluss der Entwicklung umzubenennen

Was ist der einfachste und zuverlässigste Ansatz zum Umbenennen der Datenbanktabellen und -spalten in SQL Server 2008 r2? Wir haben die Entwicklung abgeschlossen und müssen aus bestimmten Gründen einige Tabellen und einige Spalten umbenennen.

Ist die Verwendung von Synonymen der gute Weg, dies zu tun? Auf welche Fallstricke sollten wir vorbereitet sein? Hilft es auch beim ordnungsgemäßen Umbenennen der Spalten?

Wir haben viele Skripte, die sich auf diese Tabellen beziehen, und auf die in der Anwendung von .net-Entwicklern verwiesen wird.

sql-server-2008-r2

— Himmel
quelle

Ist beabsichtigt, diese Datenbankobjekte umzubenennen und eine Fassade bereitzustellen, damit vorhandene Apps nicht geändert werden müssen, um die neuen Objektnamen zu verwenden?

— Billinkc

Ich denke, der Ansatz hängt davon ab, ob die Anwendung (en) live sind oder ob Sie noch testen.

Bei Tabellen besteht der sicherste Ansatz darin, ein Synonym mit dem neuen Namen zu erstellen. Auf diese Weise können Sie die App (s) einzeln (oder sogar eine Referenz) ändern, ohne alle auf einmal ändern zu müssen. Sie müssen das Synonym nicht löschen und die Tabelle umbenennen, bis Sie sicher sind, dass alle Änderungen vorgenommen wurden.

CREATE SYNONYM dbo.NewName FOR dbo.OldName;
-- change app to point to dbo.NewName;

-- once all of your changes have been tested:
BEGIN TRANSACTION;
  DROP SYNONYM dbo.NewName;
  EXEC sp_rename N'dbo.OldName', N'NewName', N'OBJECT';
COMMIT TRANSACTION;

Für Spalten ist es etwas schwieriger. Sie können stattdessen Synonyme erstellen, die auf eine Ansicht verweisen. Abhängig von der Basistabelle müssen jedoch nicht alle Ansichten aktualisiert werden. Als einfaches Beispiel:

CREATE VIEW dbo.vNewName 
AS 
  SELECT Column1, NewColumnName = OldColumnName
    FROM dbo.OldName;

CREATE SYNONYM dbo.NewName FOR dbo.vNewName;

Wenn Sie dann wie oben alle Verweise auf Spalten und den neuen Tabellennamen geändert haben, einfach:

BEGIN TRANSACTION;
  DROP SYNONYM dbo.NewName;
  DROP VIEW dbo.vNewName;
  EXEC sp_rename N'dbo.OldName', N'NewName', N'OBJECT';
  EXEC sp_rename N'dbo.NewName.OldColumnName', N'NewColumnName', N'COLUMN';
COMMIT TRANSACTION;

Wenn die Anwendung nicht aktiv ist und noch getestet wird, benennen Sie einfach die Spalten um und beheben Sie die Fehler nach einer globalen Suche und ersetzen (oder Smart Refactor mit SSDT, RedGate usw.) durch App-Code / -Prozeduren usw.

Wenn die Anwendung aktiv ist, müssen Sie etwas vorsichtiger vorgehen.

— Aaron Bertrand
quelle

+1 für die Validierung der Änderung und die Korrektur des fehlerhaften Ansatzes, für den ich von meinem eigenen Team Mist bekomme (natürlich nur Dev Enviro)

— RThomas

Vielen Dank für Ihre gute Antwort, aber können Sie mir mitteilen, was Sie damit meinen: "Auf diese Weise können Sie die App (s) einzeln (oder sogar eine Referenz) ändern, ohne alles ändern zu müssen sie sofort. ". Meinen Sie damit, wir sollten das Synonym jeweils zu einem Zeitpunkt erstellen, z. B. zuerst Tabelle t1, Codeänderungen, dann Tabelle t2 usw.?

— Himmel

Wir befinden uns jetzt in der Entwicklungsphase, aber das System für die Komponente, die diese Tabellen umbenennen sollen, ist fast fertiggestellt. Das System wird jetzt für UAT bereitgestellt.

— Himmel

@ Nazila nein, ich meine, Sie können ein Synonym für Tabelle1 erstellen (und eines für Tabelle2, Tabelle3 usw.). Anschließend können Sie eine App, eine Klasse, ein Modul oder eine gespeicherte Prozedur ändern, um den neuen Namen über das Synonym zu verwenden. Der Rest des Codes kann weiterhin den alten Namen verwenden. Sie würden das Synonym nicht löschen und umbenennen, bis der gesamte Code aktualisiert wurde.

— Aaron Bertrand

Nun, es gibt viele Fallstricke, auf die Sie stoßen können, wenn Sie den Namen von Tabellen und Spalten ändern. Jeder andere SQL- oder Anwendungscode, der sie aufruft, muss entsprechend umbenannt werden, sonst funktioniert er nicht. Redgate stellt einige ziemlich gute Tools her, die alle Änderungen an abhängigen SQL-Ansichten / -Funktionen / -Sprocs vornehmen können. Der größte Ratschlag, den ich Ihnen geben kann, ist, diese Änderungen zuerst in einer DEV-Umgebung und dann TEST TEST TEST durchzuführen, um sicherzustellen, dass Sie den Code überall repariert haben.

— Zane
quelle