Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Renommer une table dans SQL Server (T-SQL)

Dans SQL Server, vous pouvez utiliser le sp_rename procédure stockée pour renommer un objet, y compris une table.

La plupart des autres RDBM majeurs vous permettent de renommer une table avec le ALTER TABLE déclaration, mais ce n'est pas le cas avec SQL Server.

Exemple

Voici un exemple pour illustrer :

EXEC sp_rename 't1', 't2';

Cela renomme la table appelée t1 à t2 .

Inclure le nom du schéma

Vous pouvez également qualifier la première table avec le nom du schéma, auquel cas, cela pourrait ressembler à ceci :

EXEC sp_rename 'dbo.t1', 't2';

Dans cet exemple, dbo est le nom du schéma, mais vous devrez utiliser le schéma applicable.

Inclure les noms des paramètres

Comme pour toute procédure stockée, vous pouvez également inclure les noms des paramètres lors de l'appel de sp_rename :

EXEC sp_rename 
    @objname = 'dbo.t1',
    @newname = 't2';

Le sp_rename la procédure accepte également un @objtype paramètre, mais cela n'est pas requis (ou pris en charge) lors du changement de nom des tables.

Vérifier les références

Lorsque vous renommez une table dans SQL Server, vous verrez probablement un message comme celui-ci :

Caution: Changing any part of an object name could break scripts and stored procedures.

En effet, lorsque vous renommez une table, SQL Server ne le fait pas renommer automatiquement toutes les références à cette table. Cela est également vrai lorsque vous renommez une colonne.

Malgré le message d'avertissement ci-dessus, la table est quand même renommée.

Par conséquent, avant de renommer une table, vous devez toujours vérifier les scripts et les procédures stockées qui font référence à cette table. Vous devrez mettre à jour ces scripts et procédures pour référencer le nouveau nom de table.

Vous pouvez utiliser le sys.sql_expression_dependencies vue du catalogue système pour effectuer cette vérification.

Exemple :

SELECT OBJECT_NAME(referencing_id) AS [Referencing Entity],   
    o.type_desc AS [Type],   
    COALESCE(COL_NAME(referencing_id, referencing_minor_id), '(n/a)') AS [Column],
    referenced_entity_name AS [Referenced Entity],   
    COALESCE(COL_NAME(referenced_id, referenced_minor_id), '(n/a)') AS [Column]
FROM sys.sql_expression_dependencies AS sed  
INNER JOIN sys.objects AS o ON sed.referencing_id = o.object_id  
WHERE referenced_id = OBJECT_ID(N't1');

Dans ce cas, je l'ai joint avec sys.objects pour retourner plus d'informations.

Voici le résultat que j'obtiens avant de changer le nom du t1 tableau :

+----------------------+----------------------+----------+---------------------+----------+
 | Referencing Entity   | Type                 | Column   | Referenced Entity   | Column   |
 |----------------------+----------------------+----------+---------------------+----------|
 | usp_t1               | SQL_STORED_PROCEDURE | (n/a)    | t1                  | (n/a)    |
 | vt1                  | VIEW                 | (n/a)    | t1                  | (n/a)    |
 | t1                   | USER_TABLE           | c2       | t1                  | c1       |
 +----------------------+----------------------+----------+---------------------+----------+ 

Cela me montre qu'il y a une vue, une procédure stockée et une colonne calculée qui dépendent du t1 table. La colonne calculée (c2 ) référence le c1 colonne dans le même tableau.

Comme mentionné, il est important d'exécuter cette vérification avant de modifier le nom de la table. Voici le résultat que j'obtiens en exécutant le même script après avoir changé le nom de la table.

SELECT OBJECT_NAME(referencing_id) AS [Referencing Entity],   
    o.type_desc AS [Type],   
    COALESCE(COL_NAME(referencing_id, referencing_minor_id), '(n/a)') AS [Column],
    referenced_entity_name AS [Referenced Entity],   
    COALESCE(COL_NAME(referenced_id, referenced_minor_id), '(n/a)') AS [Column]
FROM sys.sql_expression_dependencies AS sed  
INNER JOIN sys.objects AS o ON sed.referencing_id = o.object_id  
WHERE referenced_id = OBJECT_ID(N't1');

Résultat :

(0 rows affected) 

Dans ce cas, j'ai utilisé le nom d'origine de la table (t1 ), il est donc assez évident que nous n'avons même pas ciblé la bonne table (t2 ).

Changer simplement ce script pour référencer le nouveau nom de table ne fonctionnera pas non plus. Par exemple, exécuter le script suivant après avoir changé le nom de la table de t1 à t2 renvoie une seule dépendance (la colonne calculée).

SELECT OBJECT_NAME(referencing_id) AS [Referencing Entity],   
    o.type_desc AS [Type],   
    COALESCE(COL_NAME(referencing_id, referencing_minor_id), '(n/a)') AS [Column],
    referenced_entity_name AS [Referenced Entity],   
    COALESCE(COL_NAME(referenced_id, referenced_minor_id), '(n/a)') AS [Column]
FROM sys.sql_expression_dependencies AS sed  
INNER JOIN sys.objects AS o ON sed.referencing_id = o.object_id  
WHERE referenced_id = OBJECT_ID(N't2');

Résultat :

+----------------------+------------+----------+---------------------+----------+
 | Referencing Entity   | Type       | Column   | Referenced Entity   | Column   |
 |----------------------+------------+----------+---------------------+----------|
 | t2                   | USER_TABLE | c2       | t2                  | c1       |
 +----------------------+------------+----------+---------------------+----------+ 

La bonne nouvelle est que la colonne calculée est renvoyée. La mauvaise nouvelle est que la vue et la procédure stockée ne sont pas renvoyées.

Conclusion :Vérifiez les dépendances avant de renommer la table. Mettez ensuite à jour manuellement tous les objets faisant référence à la table renommée.