Y a-t-il des inconvénients aux bases de données contenues?

SQL Server 2012 a introduit le concept de base de données "contenue", dans laquelle tout (et presque tout) dont la base de données a besoin est contenu dans la base de données elle-même. Cela offre de gros avantages lors du déplacement de bases de données entre serveurs. J'aimerais donc savoir si cela devrait être ma stratégie par défaut lors de la conception d'une nouvelle base de données.

MSDN répertorie plusieurs inconvénients des bases de données contenues, les plus importants étant le manque de prise en charge du suivi des modifications et de la réplication. Y en a-t-il d'autres? Si je n'utilise pas ces fonctionnalités, y a-t-il une raison de ne pas utiliser de bases de données contenues?

L'objectif principal des bases de données contenues est de faciliter le portage de votre base de données sur un nouveau serveur sans beaucoup d'échafaudage. Dans cet esprit, je traiterai quelques problèmes potentiels qui rendront cette migration plus difficile - et la plupart tournent autour du fait que les bases de données contenues ne sont que partiellement contenues dans SQL Server 2012 (le confinement n'est pas réellement appliqué).

Chaînes de connexion

Les chaînes de connexion à une base de données contenue doivent spécifier explicitement la base de données dans la chaîne de connexion. Vous ne pouvez plus compter sur la base de données par défaut du login pour établir une connexion. Si vous ne spécifiez pas de base de données, SQL Server ne va pas parcourir toutes les bases de données contenues et essayer de trouver une base de données où vos informations d'identification peuvent correspondre.

Requêtes Cross-db

Même si vous créez le même utilisateur avec le même mot de passe dans deux bases de données contenues différentes sur le même serveur, votre application ne pourra pas effectuer de requêtes sur plusieurs bases de données. Les noms d'utilisateur et mots de passe peuvent être les mêmes, mais ils ne sont pas le même utilisateur. La raison de cela? Si vous avez contenu des bases de données sur un serveur hébergé, vous ne devriez pas être empêché d'avoir le même utilisateur contenu qu'une personne qui utilise le même serveur hébergé. Lorsque le confinement complet arrive (probablement dans la version postérieure à SQL Server 2012, jamais), les requêtes entre bases de données seront de toute façon interdites. Je vous recommande vivement de ne pas créer de connexions au niveau du serveur avec le même nom que les utilisateurs de bases de données contenues et d'éviter de créer le même nom d'utilisateur contenu dans des bases de données contenues. Si vous devez exécuter des requêtes qui touchent plusieurs bases de données contenues, utilisez un login au niveau du serveur disposant des privilèges appropriés (vous pouvez penser que c'est le cas sysadmin, mais pour les requêtes en lecture seule, il s'agit de CONNECT ANY DATABASEet SELECT ALL USER SECURABLES).

Synonymes

La plupart des noms en 3 et 4 parties sont faciles à identifier et apparaissent dans un fichier DMV. Toutefois, si vous créez un synonyme qui pointe vers un nom en 3 ou 4 parties, celles-ci n'apparaissent pas dans le fichier DMV. Par conséquent, si vous utilisez beaucoup de synonymes, il est possible que vous manquiez certaines dépendances externes, ce qui peut entraîner des problèmes au point de migrer la base de données sur un autre serveur. Je me suis plaint de ce problème, mais celui-ci a été fermé "de manière intentionnelle" et n'a pas survécu à la migration vers le nouveau système de retour d'informations . Notez que le DMV manquera également des noms en 3 et 4 parties construits via SQL dynamique.

Politique de mot de passe

Si vous avez créé un utilisateur de base de données contenu sur un système sans stratégie de mot de passe, il peut être difficile de créer le même utilisateur sur un système différent disposant d'une stratégie de mot de passe. En effet, la CREATE USERsyntaxe ne prend pas en charge le contournement de la stratégie de mot de passe. J'ai déposé un bogue à propos de ce problème et il reste ouvert (et il n'a pas non plus survécu au déménagement lorsque Connect a pris sa retraite). Et il me semble étrange que sur un système avec une stratégie de mot de passe en place, vous pouvez créer une connexion au niveau du serveur qui contourne facilement la stratégie, mais vous ne pouvez pas créer un utilisateur de base de données qui le fasse, même si cet utilisateur est intrinsèquement moins d'un risque de sécurité.

Collation

Comme nous ne pouvons plus compter sur le classement de tempdb, vous devrez peut-être modifier le code qui utilise actuellement le classement explicite ou l' DATABASE_DEFAULTutiliser à la CATALOG_DEFAULTplace. Voir cet article BOL pour des problèmes potentiels .

IntelliSense

Si vous vous connectez à une base de données contenue en tant qu'utilisateur confiné, SSMS ne prendra pas totalement en charge IntelliSense. Vous obtiendrez des soulignements de base pour les erreurs de syntaxe, mais pas de listes à remplissage automatique ni d'infobulles et tout ce qui est amusant. J'ai déposé un bogue à propos de ce problème et il reste ouvert - et un autre qui n'a pas survécu au déménagement.

Outils de données SQL Server

Si vous prévoyez d'utiliser SSDT pour le développement de bases de données, la prise en charge complète des bases de données contenues n'est actuellement pas prise en charge. Ce qui signifie simplement que la construction du projet n'échouera pas si vous utilisez une fonctionnalité ou une syntaxe qui casse le confinement, car SSDT ne sait actuellement pas ce qu'est le confinement et ce qui pourrait le rompre.

ALTER DATABASE

Lorsque vous exécutez une ALTER DATABASEcommande à partir du contexte d'une base de données contenue, ALTER DATABASE foovous devez plutôt utiliser ALTER DATABASE CURRENTce qui est nécessaire . Ainsi, si la base de données est déplacée, renommée, etc., ces commandes n'ont pas besoin de connaître leur contexte externe ou leur référence. .

Quelques autres

Certaines choses que vous ne devriez probablement pas utiliser, mais qui devraient néanmoins être mentionnées dans la liste des choses qui ne sont pas prises en charge ou qui sont déconseillées et qui ne devraient pas être utilisées dans des bases de données contenues:

• procédures numérotées
• procédures temporaires
• changements de classement dans les objets liés
• changer la capture de données
• suivi des modifications
• réplication

Cela dit, l' utilisation de bases de données contenues ne présente pas nécessairement des inconvénients , il s'agit simplement de problèmes que vous devez connaître et qui ne sont pas tous explicitement divulgués dans la documentation officielle.

Vous devez également vous assurer que, si une base de données contenue doit être migrée, ou fait partie d'un groupe de disponibilité ou est mise en miroir, que l' sp_configureoption contained database authenticationsur 1 est configurée sur tous les serveurs de destination potentiels .

Vous trouverez peut-être cet article utile, ainsi que celui-ci , bien qu'ils soient antérieurs à RTM.

Pour ceux qui sont intéressés à obtenir plus de détails sur les bases de données contenues, je leur recommande de lire cet article http://www.sqlshack.com/contained-databases-in-sql-server/

L'article identifie les principaux avantages / inconvénients de l'utilisation de bases de données contenues.

Désavantages

Les bases de données partiellement contenues ne peuvent pas utiliser des fonctionnalités telles que la réplication, la capture de données modifiées, le suivi des modifications, les objets liés au schéma qui dépendent de fonctions intégrées avec des modifications de classement.

Avantages

En revanche, comme déjà mentionné, l’utilisation de bases de données contenues présente certains avantages, tels que:

• Il est assez facile de déplacer la base de données d'un serveur à un autre,
  car il n'y aura pas de problèmes d'utilisateurs orphelins.
• Les métadonnées sont stockées dans des bases de données contenues, ce qui les rend plus faciles et plus portables.
• Il est possible d'avoir une authentification SQL Server et Windows pour les utilisateurs de base de données contenus.

L'article aide également à:

• création d'une nouvelle base de données contenue (en définissant Type de confinement comme Partiel dans la page Options de SQL Server et en utilisant une requête T-SQL pour créer une base de données par la suite)
• connexion à la base de données contenue à l'aide de SQL Server Management Studio (il est nécessaire de spécifier le nom de la base de données contenue dans le paramètre de connexion)
• convertir une base de données existante en une base de données contenue
• travailler sur une base de données contenue et répertorier toutes les connexions ayant un type d'utilisateur contenu

Un inconvénient est qu'un utilisateur de base de données contenue ne peut pas être contraint de changer son propre mot de passe, contrairement aux connexions ( MUST_CHANGE). Les utilisateurs ne peuvent pas gérer leur propre mot de passe à moins que vous ne leur accordiez une autorisation de modification d'utilisateur et leur indiquiez comment le modifier à l'aide d'une instruction SQL. Il n’est nulle part facile pour eux de le gérer via des interfaces utilisateur ou du moins, je ne sais pas comment.

Veuillez noter que j'ai trouvé l'utilisation des métadonnées inattendues et non documentées dans la clause "PIVOT" AND "UNPIVOT", ce qui, à mon avis, ne devrait figurer que dans le catalogue système (sys.tables / sys.columns / etc). Comme documenté dans msdn :

Dans une base de données contenue, le classement du catalogue Latin1_General_100_CI_AS_WS_KS_SC . Ce classement est le même pour toutes les bases de données contenues sur toutes les instances de SQL Server et ne peut pas être modifié.

Mais ils n'ont pas mentionné que la clause "PIVOT" ET "UNPIVOT" utilise également les catalogues système comme mécanisme d'exécution. elle produit donc une erreur de collation en conflit partout autour de l'utilisation de la clause "PIVOT" ET "UNPIVOT" pendant la migration. voici quelques repro:

/*step1 create a table belongs to a contained database and populate some data*/
create  table dbo.test1 (col1 varchar(100),col2 varchar(100))
insert  dbo.test1 values('a','x')
insert  dbo.test1 values('b','y')
insert  dbo.test1 values('c','z')

/*step2 lets see its collation you will see it is correctly as same as its (contained) database */
select name,collation_name from sys.columns where object_name(object_id) = 'test1'

/*step3 reproduce an unpivoted column*/
select * into dbo.test2
from (select * from dbo.test1) a unpivot (val for col in (col1,col2)) a


/*step4 lets check its collation you will see the column specified at "FOR" clause is created as Latin1_General_100_CI_AS_KS_WS_SC */
select name,collation_name from sys.columns where object_name(object_id) = 'test2'

/*step5 make use of the unpivoted table without awareness will cause an error*/
select val + ' = ' + col from dbo.test2 

/*step6 clean up*/
drop table dbo.test1
drop table dbo.test2

vous pouvez également voir que les articles sur la base de données contenue sont pour la plupart incomplets. donc décider de l'utiliser nécessite une très bonne improvisation.