When contained databases were introduced in SQL Server 2012, I thought they were a very nice enhancement to the platform. The idea of having security managed inside the database, thereby removing the problem of orphaned users, was something I looked forward to. Preventing collation conflicts is also a nice benefit, though I've never had a problem with this issue. However I was, and still am, hoping that this was just the beginning of what a contained database would be. I had a vision of a self-describing database.
There are many things that we need to manage with databases: maintenance, backups, auditing, performance statistics, alerts, and more. Most of these are set up at the instance, but I've never quite understood why. Software should help us work more efficiently, and work with us, not against us. So many of these administrative items are dependent on the needs of a particular database or application, but we perform all these actions at the instance level.
Backups are an example of a database dependent item, as we constantly teach new DBAs. However the backup plans are set at the instance level, and if you have disparate requirements for different databases, these result in different backup plans. The MSDN documentation says we should even have a manual for each database. If that's the case, why is the information about a database backup stored outside of the database? I think it would make more sense for the backup plan to be stored in the database, and when the database is attached, or the plan created, the instance would read this plan and create the necessary jobs. If we detached the database, the jobs would be removed. We run recovery in each database, couldn't that serve to enable or disable any alerts, jobs, etc. for any database that wasn't accessible?
I envision much more than just backups as being a part of the database. Every action we need to manage in a database from alerts to auditing, should be stored there. Let the Agent on the instance read the database and automatically set up the jobs needed. If there are conflicts with scheduling, alert the DBA at the instance level, but keep the metadata about the needs of the database in the database. It would make consolidation, or movement of databases much simpler. It would also fit with the idea of a database service, rather than a database server.
Steve Jones
The Voice of the DBA Podcasts
We publish three versions of the podcast each day for you to enjoy.
- Watch the Windows Media Podcast - 18.5MB WMV
- Watch the iPod Video Podcast - 22.3MB MP4
- Listen to the MP3 Audio Podcast - 4.4MB MP3
The podcast feeds are available at sqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there. Overall RSS Feed: 
or now on iTunes! 
Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
You can also follow Steve Jones on Twitter:
