今天看来这个机制带来了如下两个问题：

1.       提高了高可用解决方案的维护成本。举例来说，对于一个启用了数据库镜像的系统，如果你在主体服务器上添加了新的登录名来访问镜像数据库的话，你必须在镜像服务器上也添加相同的登录名，否则一旦发生了故障转移，数据库就无法使用新的登录名进行访问。另外，在镜像服务器上添加登录名时要确保和主体服务器上的登录名使用相同的SID。否则就会破坏登录名到数据库用户之间的对应关系，成为所谓的孤立用户。

迁移Login可以参考：How to transfer logins and passwords between instances of SQL Serverhttp://support.microsoft.com/kb/246133 

2.       增加了迁移应用的复杂程度。应用程序所需要的数据都保存在用户数据库中，但是当你需要将应用从开发坏境迁移到生产环境，或者从老的服务器迁移到新的服务器上的时候，你不能仅仅简单的迁移用户数据库和程序。因为还有一部分和应用相关的数据遗漏在用户数据库之外，其中包括登录名。在迁移应用的时候，登录名需要被单独的从老的环境中提取出来，再部署到新环境上。

为了解决这样的问题，SQL Server 2012引入了新的特性，叫做Contained Database认证。Contained Database认证主要是由两类对象构成整个认证体系，一个叫做Contained Database。另一个是创建在Contained Database中的用户对象，被称为Contained database user。Contained database，顾名思义，就是将应用所需要的所有信息全部“包含”在用户数据库内部，不遗漏在系统数据库中。当应用程序连接contained database的时候，它不需要通过记录在master数据库中的登录名然后再映射到数据库用户，而是直接在contained database上进行验证，然后获得对应的contained database user被授予的权限进行数据库操作。可以说Contained database user就是一个把传统的登录名和数据库用户名的功能揉在一起的一种新的对象类型。有个Contained Database认证，上面谈到的两个问题就能很简单的得到解决。

Contained Database认证并不是独立于传统的Windows认证和SQL认证之外的新的认证方式，而是建立在这两种认证方式之上的新功能。也就是说，登录到SQL Server的账号依旧需要通过Windows认证或SQL Server认证的机制来验明正身，只是一旦验证通过该账号就会直接被转换成一个数据库用户。因此你根本不需要在实例中为该账户建立任何对应的登录名。

--在SQL Server上 enable containeddatabase认证

EXECsp_configure'show advanced options', 1;

GO

RECONFIGUREWITHOVERRIDE;

GO

EXECsp_configure'contained databaseauthentication', 1;