Comment migrer entre des schémas en bloc dans SQL Server?

Nous avons actuellement plusieurs bases de données, mais nous aimerions les combiner et, au lieu de cela, séparer nos contextes de domaine à l'aide de schémas.

Dans MS SQL Server 2008 R2, comment déplacer en bloc tout le contenu d'un schéma dans un autre?

Par exemple, toutes les tables, vues, procédures, index, etc. que nous avons créées dans le dboschéma vivront désormais dans le fooschéma.

EDIT: Je voulais clarifier sur la base des excellents commentaires d'AaronBertrand. Ce n'est pas une situation de location multiple. Notre situation est celle où les plugins d'outils internes ont été développés de manière isolée par des développeurs qui n'ont pas fusionné leurs tables dans la base de données de l'outil.

Le concept de base est en fait assez simple: vous générez un script à partir de sys.objectset sys.schemasqui construit des ALTER SCHEMA TRANSFERinstructions. Ainsi, par exemple, vous avez trois objets dans le dboschéma et vous souhaitez tous les déplacer vers le blatschéma:

Table: dbo.foo
Table: dbo.bar
View:  dbo.vFooBar

Le code suivant:

DECLARE @sql NVARCHAR(MAX) = N'';

SELECT @sql += N'
  ALTER SCHEMA blat TRANSFER dbo.' + QUOTENAME(o.name) + ';'
FROM sys.objects AS o
INNER JOIN sys.schemas AS s
ON o.[schema_id] = s.[schema_id]
WHERE s.name = N'dbo';

PRINT @sql;
-- EXEC sp_executesql @sql;

Donnera ce script (mais peut-être pas dans cet ordre):

ALTER SCHEMA blat TRANSFER dbo.bar;
ALTER SCHEMA blat TRANSFER dbo.foo;
ALTER SCHEMA blat TRANSFER dbo.vFooBar;

(Vous souhaiterez peut-être ajouter des filtres supplémentaires pour exclure les objets du dboschéma que vous ne souhaitez pas déplacer, exclure certains types d'objet (par exemple, toutes vos fonctions sont des fonctions utilitaires et n'ont pas besoin de se déplacer), générez le script ordonné par type d'objet, etc.)

Mais il y a quelques problèmes avec le déplacement de tous vos objets vers un nouveau schéma:

1. Probablement, votre code fera toujours référence à ces objets dbo.object- il n'y a pas de moyen facile de résoudre ce problème, sauf la force brute. Vous pouvez probablement trouver toutes les occurrences de dbo.assez facilement, mais celles-ci peuvent également renvoyer des faux positifs, tels que EXEC dbo.sp_executesql, dbo.dans les commentaires, de vraies références à des objets qui restent dans le dbo.schéma, etc.

2. Vos dépendances seront probablement complètement hors de contrôle, mais je n'ai pas testé cela à fond. Je sais que dans ce scénario:

   CREATE SCHEMA blat AUTHORIZATION dbo;
   GO
   
   CREATE TABLE dbo.foo(a INT PRIMARY KEY);
   CREATE TABLE dbo.bar(a INT FOREIGN KEY REFERENCES dbo.foo(a));
   GO
   
   CREATE PROCEDURE dbo.pX AS
   BEGIN
     SET NOCOUNT ON;
     SELECT a FROM dbo.bar;
   END
   GO
   
   CREATE VIEW dbo.vFooBar
   AS
     SELECT foo.a, bar.a AS barA
       FROM dbo.foo 
       INNER JOIN dbo.bar
       ON foo.a = bar.a;
   GO
   
   ALTER SCHEMA blat TRANSFER dbo.foo;
   ALTER SCHEMA blat TRANSFER dbo.bar;
   ALTER SCHEMA blat TRANSFER dbo.pX;
   ALTER SCHEMA blat TRANSFER dbo.vFooBar;
   

   Les clés étrangères migrent en fait plus facilement que prévu (avec la mise en garde que je teste sur une version beaucoup plus récente que vous). Mais parce que le code fait blat.pXtoujours référence dbo.bar, exécutant évidemment la procédure:

   EXEC blat.pX;

   Va produire cette erreur:

   Msg 208, niveau 16, état 1, procédure pX
   Nom d'objet non valide 'dbo.bar'.

   Et les requêtes de dépendance, telles que:

   SELECT * FROM sys.dm_sql_referenced_entities('blat.pX', N'OBJECT');

   Donnera cette erreur:

   Msg 2020, niveau 16, état 1
   Les dépendances signalées pour l'entité "blat.pX" peuvent ne pas inclure de références à toutes les colonnes. Cela est dû au fait que l'entité fait référence à un objet qui n'existe pas ou à cause d'une erreur dans une ou plusieurs instructions de l'entité. Avant de réexécuter la requête, assurez-vous qu'il n'y a pas d'erreur dans l'entité et que tous les objets référencés par l'entité existent.

   Et interroger la vue:

   SELECT a, barA FROM blat.vFooBar;

   Donne ces erreurs:

   Msg 208, niveau 16, état 1, procédure vFooBar
   Nom d'objet non valide 'dbo.foo'.
   Msg 4413, niveau 16, état 1
   Impossible d'utiliser la vue ou la fonction «blat.vFoobar» en raison d'erreurs de liaison.

   Donc, cela pourrait impliquer beaucoup de nettoyage. Et après avoir corrigé toutes les références d'objet, vous souhaiterez probablement recompiler tous les modules et actualiser toutes les vues dans le nouveau schéma. Vous pouvez générer un script pour cela assez similaire à l'exemple ci-dessus.