MSDN列出了包含数据库的几个缺点,而重要的是缺乏对变更跟踪和复制的支持.还有其他人吗？如果我不打算使用这些功能,是否有任何理由不使用包含的数据库？
解决方法
连接字符串
包含数据库的连接字符串必须在连接字符串中显式指定数据库.您不能再依赖登录的默认数据库来建立连接;如果您未指定数据库,则sql Server不会单步执行所有包含的数据库,并尝试查找您的凭据可能匹配的任何数据库.
即使您在同一服务器上的两个不同的包含数据库中创建具有相同密码的相同用户,您的应用程序也将无法执行跨数据库查询.用户名和密码可能相同,但它们不是同一个用户.这是为什么？如果您在托管服务器上包含数据库,则不应阻止您使用与恰好使用相同托管服务器的其他人相同的包含用户.当完全包含到来时(可能在sql Server 2012之后的版本中),无论如何都绝对会禁止跨数据库查询.我强烈建议您不要创建与包含数据库用户同名的服务器级别登录,并尽量避免在包含的数据库中创建相同的包含用户名.如果您需要运行命中多个包含数据库的查询,请使用具有适当权限的服务器级别登录(您可能认为这是sysadmin,但对于只读查询,这是CONNECT ANY DATABASE和SELECT ALL USER SECURABLES) .
同义词
大多数3和4部分名称易于识别,并出现在DMV中.但是,如果您创建指向3或4部分名称的同义词,则这些名称不会显示在DMV中.因此,如果您大量使用同义词,则可能会遗漏一些外部依赖项,这可能会导致将数据库迁移到其他服务器时出现问题. I complained about this issue,but it was closed as “by design”并没有幸免于迁移到new feedback system.请注意,DMV也会错过通过动态sql构建的3和4部分名称.
密码政策
如果您在没有密码策略的系统上创建了包含数据库用户,则可能会发现很难在具有密码策略的其他系统上创建相同的用户.这是因为CREATE USER语法不支持绕过密码策略. I filed a bug about this problem,and it remains open(当Connect退役时,它也无法幸免.)我觉得奇怪的是,在一个有密码策略的系统上,你可以创建一个服务器级登录,轻松绕过策略,但你不能创建一个这样做的数据库用户 – 即使这个用户本身就是这样减少安全风险.
整理
由于我们不能再依赖tempdb的排序规则,您可能需要更改当前使用显式排序规则或DATABASE_DEFAULT的任何代码来改为使用CATALOG_DEFAULT.见this BOL article for some potential issues.
智能感知
如果以包含的用户身份连接到包含的数据库,则SSMS将不完全支持IntelliSense.您将获得语法错误的基本下划线,但没有自动完成列表或工具提示以及所有有趣的东西. I filed a bug about this issue,and it remains open – 还有一个没能幸免于此.
sql Server数据工具
如果您计划使用SSDT进行数据库开发,则目前尚未完全支持包含的数据库.这真的只是意味着如果你使用一些破坏包含的功能或语法,构建项目不会失败,因为SSDT目前不知道什么是包含,什么可能会破坏它.
ALTER DATABASE
当从包含数据库的上下文中运行ALTER DATABASE命令时,rRather比ALTER DATABASE foo需要使用ALTER DATABASE CURRENT – 这样如果数据库被移动,重命名等,这些命令就不需要了了解他们的外部背景或参考.
其他几个
您可能不应该使用的一些内容但是应该在不受支持或不推荐使用的内容列表中提及,不应在包含的数据库中使用：
>编号程序
>临时程序
>绑定对象中的排序规则更改
>改变数据捕获
>改变跟踪
>复制
总而言之,这些并不一定是使用包含数据库的缺点,它们只是您应该知道的问题,并未在官方文档中明确公开.
您还需要确保如果要迁移包含的数据库,或者是可用性组的一部分或正在镜像,则所有潜在目标服务器都将包含数据库身份验证的sp_configure选项设置为1.
您可能会发现this blog post和this one一样有用,即使它们早于RTM.
