SQL Server 2005

  • Comments posted to this topic are about the item SQL Server 2005

    Thanx.
    Vinay

    http://rdbmsexperts.com/Blogs/
    http://vinay-thakur.spaces.live.com/
    http://twitter.com/ThakurVinay

  • Thanks. To be frank I was not aware about it.

    And I have never seen anybody using it as well.

  • And according to BOL is already obsolete. Btw anybody find it useful?

  • I didn't realize that it was already obsolete up until now. I have tested this for a very large DW and have seen significant disk space savings.

  • It was introduced for data warehouses and cubes, offering savings if you store significant amounts of decimal data.

  • I found it usefull in a large database on a server with many CPU:s and I/0 bottleneck, but now we have replaced it with table compression in SQL server 2008, and it is much more usefull. (We have 4 quad processors 🙂 )

    /Håkan Winther
    MCITP:Database Developer 2008
    MCTS: SQL Server 2008, Implementation and Maintenance
    MCSE: Data Platform

  • It's hard to understand why MS introduced this storage format - perhaps they hadn't yet decided to provide table compression in the next version when they did this (although one would thing SQL2008 was in a pretty advanced stage by the time SQL2005 SP2 content was defined). Using a long format + compression (store the affected tables on a compressed partition in older or less facility-rich SQLServer versions ; use SQL table compression if you have the right SQL version) is going to be far cleaner and give greater savings almost always. Of course if you have a very large very sparse matrix of decimal values, and want to store it in fully expanded form (ie as if it were not sparse) in a table it's possible that vardecimal might do as well as or maybe even better than compression, but (a) I think it's unlikely that vardecimal actually would do better and (b) I really can't imagine anyone wanting to do that.

    Tom

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply