c4ntaloop (7/11/2013)
So that makes me think in what real scenario do we want to use contained database? We know that it can have contained users and solve collation issue, which makes a contained db is very portable and can be migrated easily anytime. But in what real case or why one want to sacrifice those features for the sake of easy migration. Can anyone please shed a light.
Obviously it is a trade-off. If you want the ease of database logins, and easier collation handling, and you think that that none of the features not supported in a partially contained database are of interest for you, then a contained database is a good choice.
The problem is only know when you don't need any of those other feature. You may not need Service Broker or Change Tracking today, but who knows what needs you may have three years from now?
I think the idea of a contained database is very good, but what is offered in SQL 2012 is too half-baked, to be really useful.
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]