The primary purpose of contained databases is to make it easier to port your database to a new server without a lot of scaffolding around it. With that in mind, I'll treat a few potential issues that will make this migration more difficult - and most revolve around the fact that contained databases are only partially contained in SQL Server 2012 (containment is not actually enforced).
Connection strings to a contained database must explicitly specify the database in the connection string. You can no longer rely on the login's default database to establish a connection; if you don't specify a database, SQL Server is not going to step through all the contained databases and try to find any database where your credentials may match.
Even if you create the same user with the same password in two different contained databases on the same server, your application will not be able to perform cross-database queries. The usernames and passwords may be the same, but they're not the same user. The reason for this? If you have contained databases on a hosted server, you shouldn't be prevented from having the same contained user as someone else who happens to be using the same hosted server. When full containment arrives (likely
in the version after SQL Server 2012 never), cross-database queries will absolutely be prohibited anyway. I highly, highly, highly recommend that you don't create server-level logins with the same name as contained database users, and try to avoid creating the same contained user name across contained databases. If you need to run queries that hit multiple contained databases, do so using a server-level login that has appropriate privileges (you might think this is
sysadmin, but for read-only queries, this is
CONNECT ANY DATABASE and
SELECT ALL USER SECURABLES).
Most 3- and 4-part names are easy to identify, and appear in a DMV. However if you create a synonym that points to a 3- or 4-part name, these do not show up in the DMV. So if you make heavy use of synonyms, it is possible that you will miss some external dependencies, and this can cause problems at the point where you migrate the database to a different server. I complained about this issue, but it was closed as "by design" and didn't survive the migration to the new feedback system. Note that the DMV will also miss 3- and 4-part names that are constructed via dynamic SQL.
If you have created a contained database user on a system without a password policy in place, you may find it hard to create the same user on a different system that does have a password policy in place. This is because the
CREATE USER syntax does not support bypassing the password policy. I filed a bug about this problem, and it remains open (and it also didn't survive the move when Connect was retired). And it seems strange to me that on a system with a password policy in place, you can create a server-level login that easily bypasses the policy, but you can't create a database user that does so - even though this user is inherently less of a security risk.
Since we can no longer rely on the collation of tempdb, you may need to change any code that currently uses explicit collation or
DATABASE_DEFAULT to use
CATALOG_DEFAULT instead. See this BOL article for some potential issues.
If you connect to a contained database as a contained user, SSMS will not fully support IntelliSense. You'll get basic underlining for syntax errors, but no auto-complete lists or tooltips and all the fun stuff. I filed a bug about this issue, and it remains open - and one more that did not survive the move.
SQL Server Data Tools
If you are planning to use SSDT for database development, there currently isn't full support for contained databases. Which really just means that building the project won't fail if you use some feature or syntax that breaks containment, since SSDT currently doesn't know what containment is and what might break it.
When running an
ALTER DATABASE command from within the context of a contained database, rRather than
ALTER DATABASE foo you will need to use
ALTER DATABASE CURRENT - this is so that if the database is moved, renamed, etc. these commands don't need to know anything about their external context or reference.
A few others
Some things you probably shouldn't still be using but nonetheless should be mentioned in the list of things that aren't supported or are deprecated and shouldn't be used in contained databases:
- numbered procedures
- temporary procedures
- collation changes in bound objects
- change data capture
- change tracking
That all said, these aren't necessarily disadvantages to using contained databases, they're just issues you should be aware of and aren't all explicitly disclosed in the official documentation.
You'll also need to be sure that if a contained database is going to be migrated, or is part of an availability group or is being mirrored, that all potential destination servers have the
contained database authentication set to 1.
You may find this blog post useful, as well as this one, even though they pre-date RTM.