La meilleure façon de renommer les tables une fois le développement terminé


8

Quelle est l'approche la plus simple et la plus fiable pour renommer les tables et les colonnes de base de données dans SQL Server 2008 r2? Nous avons terminé le développement et pour certaines raisons, nous devons renommer certaines tables et quelques colonnes.

Est-ce que l'utilisation de synonymes est la bonne façon de procéder? À quels pièges devons-nous nous préparer? Cela aide-t-il également à renommer les colonnes avec élégance?

Nous avons beaucoup de scripts liés à ces tables et ils sont également référencés dans l'application par les développeurs .net.


L'intention est-elle de renommer ces objets de base de données et de fournir une façade afin que les applications existantes n'aient pas besoin d'être modifiées pour utiliser les nouveaux noms d'objet?
billinkc

Réponses:


10

Je pense que l'approche dépend de si les applications sont en direct ou si vous testez toujours.

Pour les tableaux, l'approche la plus sûre consiste à créer un synonyme en utilisant le nouveau nom. De cette façon, vous pouvez modifier les applications une par une (ou même une référence à la fois), sans avoir à les modifier toutes en même temps. Vous n'avez pas besoin de supprimer le synonyme et de renommer la table tant que vous n'êtes pas sûr d'avoir toutes les modifications en place.

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;

Pour les colonnes, c'est un peu plus délicat. Vous pouvez créer des synonymes qui pointent vers une vue à la place, mais toutes les vues ne seront pas nécessairement actualisables en fonction de la table de base. Comme exemple simple:

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

CREATE SYNONYM dbo.NewName FOR dbo.vNewName;

Ensuite, comme ci-dessus, lorsque vous avez modifié toutes les références aux colonnes et le nouveau nom de table, simplement:

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;

Si l'application n'est pas en ligne et est toujours en cours de test, renommez simplement les colonnes et corrigez ce qui se casse après une recherche globale et remplacez (ou refactor intelligent à l'aide de SSDT, RedGate, etc.) via le code / les procédures d'application, etc.

Si l'application est en direct, vous devrez avancer un peu plus délicatement.


+1 pour valider le changement et corriger ce qui a cassé l'approche que je reçois de la merde de ma propre équipe (dev enviro seulement bien sûr)
RThomas

Merci pour votre bonne réponse, mais seriez-vous en mesure de me dire ce que vous entendez par: "De cette façon, vous pouvez changer les applications une par une (ou même une référence à la fois), sans avoir à tout changer à la fois. ". Voulez-vous dire que nous devrions créer le synonyme un à la fois, par exemple la première table t1, le code change-t-il, puis la table t2, etc.?
Sky

Nous sommes maintenant dans la phase de développement, mais le système est presque terminé pour ce composant que ces tables doivent être renommées. Le système est maintenant déployé sur UAT.
Sky

1
@Nazila non, je veux dire que vous pouvez créer un synonyme pour table1 (et un pour table2, table3, etc.). Vous pouvez ensuite modifier une application, ou une classe, ou un module, ou une procédure stockée pour utiliser le nouveau nom via le synonyme. Le reste du code peut continuer à utiliser l'ancien nom. Vous ne laisseriez pas tomber le synonyme et le renommeriez jusqu'à ce que tout le code soit mis à jour.
Aaron Bertrand

0

Eh bien, vous pouvez rencontrer de nombreux pièges lorsque vous changez le nom des tables et des colonnes. Tout autre code SQL ou d'application qui les appelle devra être renommé pour correspondre ou cela ne fonctionnera pas. Redgate fait de très bons outils qui peuvent passer et apporter toutes les modifications aux veiws / fonctions / sprocs SQL dépendants. Le plus gros conseil que je puisse vous donner est de faire d'abord ces changements dans un environnement DEV et TEST TEST TEST pour vous assurer d'avoir corrigé le code partout.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.