Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

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.

Comments

Posted by Steve Jones on 17 May 2010

Master as default is interesting. So should we force a user db to be created at install? Some default location?

Posted by Jason Brimhall on 17 May 2010

I like your list.  I, too, am not a fan of the Master DB being the default database.

Posted by Jack Corbett on 17 May 2010

I set my default to tempdb, why not make that the default.

I normally set a default database for users to the first database they are in.

Posted by Anonymous on 18 May 2010

Pingback from  Dew Drop – May 18, 2010 | Alvin Ashcraft's Morning Dew

Posted by Anonymous on 18 May 2010

Pingback from  Twitter Trackbacks for                 SQL Server Central, 5 Features SQL Server Doesn???t Need - Wise Man or Wise Guy         [sqlservercentral.com]        on Topsy.com

Posted by Dukagjin Maloku on 19 May 2010

I set as default database, DBs where the users will connect everyday.

Posted by Dukagjin Maloku on 19 May 2010

hehe it's not bad I set my default to tempdb - lol.

Leave a Comment

Please register or log in to leave a comment.