在SQL Server 2012中，他们介绍了Contained Database。这个功能的真正目的是什么？以前版本的哪些缺点已修复？
答案 0 :(得分：8)
正在开发它们，以便更容易地在系统之间迁移数据库（您的数据库和SQL Azure上的数据库需要移动以平衡资源）。任何具有数据库外部依赖的东西都被认为是一种风险，因为它是与数据库一起使用的额外脚手架 - 容易忘记，容易出错，容易失去同步。 / p>
例如，在Denali中解决了这些问题：
今天，当您将数据库移动到另一台服务器时，您还必须在服务器级别迁移所有SQL登录 - 这可能会很麻烦，尤其是当SID不同步时。对于包含的数据库，当数据库备份，分离，镜像，复制等时，与数据库级别的用户没有绑定到SQL Server登录，因此非常容易。
< / LI>如果您的数据库的排序规则与服务器排序规则不同，则在使用#temp表连接或执行其他操作时可能会发现存在排序规则冲突，因为创建的#temp表将继承服务器排序规则，而不是调用数据库。虽然您可以通过在包含数据库的每个单个列引用上指定COLLATE子句来解决这个问题，但#tempdb会继承调用数据库的排序规则，从而覆盖服务器排序规则。
THROW（）几乎也属于这一类 - 因为您不再需要使用sys.messages来存储自定义消息。这不像上面两个问题那么常见，但如果不需要同时保持sys.messages，它肯定会使迁移到新服务器的工作更好。这不仅限于包含数据库，但它起着相同的作用。
对于不符合“遏制”标准的内容，有一个DMV可以向您显示如果将它们移动到另一台服务器可能会中断的内容列表。例如，调用三个或四个部分的名称。
在未来的版本中，还有其他问题需要解决。例如：
SQL Server代理是外部依赖项。当您将数据库移动到其他服务器时，引用该数据库的SQL代理作业不会随数据库自动移动，您必须确定哪些受影响并自行编写脚本（这不像只带来msdb那么简单）太）。在SQL Server的未来版本中，我设想（a）每个数据库都能够拥有自己的代理，或者（b）代理将被移动到OS级架构，其中一些转换层告诉你数据库的位置是，而不是必须让代理在同一台机器上运行。当我们谈论Azure，地理不同的网络等时，后一种选择会变得复杂。
链接服务器也是外部依赖项。这可以通过数据库级链接服务器轻松解决 - 特别是因为它们只是同义词容器/指针。
还有其他人，但那些是重击手。