包含数据库有缺点吗?

Mar*_*ark 33 sql-server sql-server-2012

SQL Server 2012 引入了“包含”数据库的概念,其中数据库需要的所有内容(好吧,几乎所有内容)都包含在数据库本身中。在服务器之间移动数据库时,这提供了很大的优势。那么,我想知道,这是否应该是我设计新数据库时的默认策略。

MSDN 列出了包含数据库的几个缺点,最大的缺点是缺乏对更改跟踪和复制的支持。还有其他人吗?如果我不打算使用这些功能,是否有任何理由不使用包含的数据库?

Aar*_*and 33

包含数据库的主要目的是让您更轻松地将数据库移植到新服务器,而无需在其周围放置大量脚手架。考虑到这一点,我将讨论一些会使迁移变得更加困难的潜在问题 - 大多数问题都围绕这样一个事实,即 SQL Server 2012 中仅部分包含包含的数据库(实际上并未强制执行包含)。


连接字符串

到包含数据库的连接字符串必须在连接字符串中明确指定数据库。您不能再依赖登录的默认数据库来建立连接;如果您不指定数据库,SQL Server 将不会遍历所有包含的数据库并尝试查找您的凭据可能匹配的任何数据库。


跨数据库查询

即使您在同一台服务器上的两个不同的包含数据库中使用相同的密码创建相同的用户,您的应用程序也将无法执行跨数据库查询。用户名和密码可能相同,但它们不是同一用户。这是什么原因?如果您在托管服务器上包含数据库,则不应阻止您拥有与碰巧使用同一托管服务器的其他人相同的包含用户。当完全遏制到达时(可能在 SQL Server 2012 之后的版本中 从未),无论如何都绝对禁止跨数据库查询。我强烈、强烈、强烈建议您不要创建与包含的数据库用户同名的服务器级登录名,并尽量避免在包含的数据库中创建相同的包含用户名。如果您需要运行命中多个包含数据库的查询,请使用具有适当权限的服务器级登录(您可能认为这是sysadmin,但对于只读查询,这是CONNECT ANY DATABASESELECT ALL USER SECURABLES)。


同义词

大多数由 3 部分和 4 部分组成的名称很容易识别,并出现在 DMV 中。但是,如果您创建一个指向 3 部分或 4 部分名称的同义词,则这些名称不会显示在 DMV 中。因此,如果大量使用同义词,则可能会遗漏一些外部依赖项,这可能会在将数据库迁移到其他服务器时导致问题。我抱怨过这个问题,但它是“按设计”关闭的,并且在迁移到新的反馈系统后无法生存。请注意,DMV 还会遗漏通过动态 SQL 构建的 3 部分和 4 部分名称。


密码政策

如果您在没有适当密码策略的系统上创建了包含数据库用户,您可能会发现很难在有适当密码策略的不同系统上创建相同的用户。这是因为CREATE USER语法不支持绕过密码策略。我提交了一个关于这个问题的错误,它仍然是开放的(当 Connect 退役时,它也没有幸免于难)。我觉得奇怪的是,在一个有密码策略的系统上,你可以创建一个服务器级别的登录来轻松绕过该策略,但是你不能创建一个这样做的数据库用户 - 即使这个用户本质上是较少的安全风险。


整理

由于我们不能再依赖 tempdb 的排序规则,您可能需要更改当前使用显式排序规则的任何代码或DATABASE_DEFAULT改为使用CATALOG_DEFAULT。有关一些潜在问题,请参阅此 BOL 文章


智能感知

如果您以包含的用户身份连接到包含的数据库,SSMS 将不完全支持 IntelliSense。您将获得语法错误的基本下划线,但没有自动完成列表或工具提示以及所有有趣的东西。我提交了一个关于这个问题的错误,它仍然是开放的- 还有一个没有在移动中幸存下来。


SQL Server 数据工具

如果您计划使用 SSDT 进行数据库开发,目前还没有完全支持包含的数据库。这实际上只是意味着如果您使用某些破坏遏制的功能或语法,构建项目不会失败,因为 SSDT 目前不知道什么是遏制以及什么可能破坏它。


更改数据库

ALTER DATABASE从包含的数据库的上下文中运行命令时,r 而不是ALTER DATABASE foo您需要使用ALTER DATABASE CURRENT- 这是为了如果数据库被移动、重命名等,这些命令不需要知道关于它们的外部上下文或引用的任何信息.


其他几个

有些东西你可能不应该仍然使用,但仍然应该在不支持或不推荐使用的东西列表中提到,不应该在包含的数据库中使用:

  • 编号程序
  • 临时程序
  • 绑定对象中的排序规则更改
  • 更改数据捕获
  • 变更追踪
  • 复制

话虽如此,这些不一定是使用包含数据库的缺点,它们只是您应该注意的问题,并没有在官方文档中明确披露。

您还需要确保如果包含的数据库将被迁移,或者是可用性组的一部分或正在被镜像,则所有潜在的目标服务器都将sp_configure选项contained database authentication设置为 1。

您可能会发现这个博客帖子是有用的,以及这一次,即使他们预先日期RTM。

  • @JonSeigel 他们仍然被允许在部分遏制下,但他们违反了遏制(意味着无法验证程序访问的实体,因为它的元数据和定义存储在其他地方)所以不推荐。来自 http://msdn.microsoft.com/en-us/library/ff929071.aspx#Limitations:*当前允许使用临时存储过程。由于临时存储过程违反了限制,因此预计未来版本的包含数据库将不支持它们。* (2认同)

Ale*_*lov 9

对于那些有兴趣获得有关包含数据库的更多详细信息的人,我可以推荐他们阅读这篇文章http://www.sqlshack.com/contained-databases-in-sql-server/

文章指出了使用包含数据库的主要优点/缺点。

缺点

部分包含的数据库不能使用诸如复制、更改数据捕获、更改跟踪、依赖于具有排序规则更改的内置函数的模式绑定对象等功能。

好处

另一方面,如前所述,使用包含的 DB 有一些好处,例如:

  • 将数据库从一台服务器移动到另一台服务器非常容易,
    因为不会出现孤立用户问题
  • 元数据存储在包含的数据库中,因此更容易和更便携
  • 可以对包含的数据库用户进行 SQL Server 和 Windows 身份验证

文章还有助于:

  • 创建新的包含数据库(通过在 SQL Server 的“选项”页面中将包含类型设置为“部分”,然后使用 T-SQL 查询创建数据库)
  • 使用 SQL Server Management Studio 连接到包含的 DB(需要在连接参数中指定包含的 DB 名称)
  • 将现有数据库转换为包含数据库
  • 处理包含的数据库并列出包含用户类型的所有登录名