5 Features SQL Server Doesn’t Need

Paul Randal (@PaulRandal) started this chain of blog posts with his post, What 5 Things Should SQL Server Get Rid Of? and I was tagged by Michelle Ufford (@SQLFool) in her post, Delete 5_Useless_Things FROM [SQL Server].  Many will be repeats, but that’s partly because SQL Server is such a good product and mostly because some features cause more problems than they solve.

1. Autoclose – I don’t know of anyone who uses it and I can’t think of any reason why you would want to use it.  Even most base laptops running SQL Server Express have enough resources to keep databases open.
2. Autoshrink – another one mentioned by almost everyone.  It causes more problems than it solves.  As a matter of fact I can’t think of any problems it actually solves in this day of terabyte drives, raid arrays, and SANS.
3. Encryption of Stored Procedures, Functions, and Views – Odds are whatever you are doing in T-SQL has been done before.  Not only has it been done before, but it has probably been published on a blog.  Jeremiah Peschka (@peschkaj) covers this in his recent post, Encrypted Stored Procedures and Their Effect on my Rug.
4. Master as the default database – changing and adding objects to the master database is not a recommended practice, so why would you make that the default database context when a user connects to SQL Server without specifying a database or having a default specified?
5. Primary Key Defaulting to the Clustered Index – Sure, often times the primary key is a surrogate key which is narrow, unchanging, and monotonically increasing so it may be a good choice for a clustered index, but this isn’t always the case.  A Primary Key is a constraint so I should have to choose if it is a clustered index or not.

You can check out Paul’s blog to see many of the other posts in this meme.  I’m a bit late to the party and I think most people I know I have already been tagged so I won’t be tagging anyone this time around.