SQL Server 2008已经发布，我们可以看到它在各方面都有了显着的进步，这些让人侧目之处和失望之处都有可能极大地影响大型企业的采购意向。

   微软SQL Server 2008的开发代号是Katmai，这个名字来源于阿拉斯加半岛东端阿拉斯加州北部阿留申山区的一座活火山，对数据库而言，可能并不是个最好的比喻（嘿嘿，目前为止，Katmai火山还没有在我头上爆发过）。低调的Katmai看起来似乎是Yukon的一个好的接班人，而Yukon是SQL Server 2005的开发代号。

   在基于对SQL Server 2005彻底的、面向企业的改进之后，Katmai为大规模部署带来了非常引人注目的特性，比如数据库引擎中的数据及备份压缩、稀疏列、压缩与过滤索引，这些功能都是为了节省存储空间，环保、绿色；另外，别忘了还有Change Data Capture，其在表中捕捉生成数据的差别，以便更新数据仓库。

   这些都只不过是冰山一角（喔，不是冰山是火山），还有许多其他的新特性，如基于策略的管理——这是针对中小企业和大型企业的，不仅这些，SQL Server 2008的各个方面都让人留下了深刻的印象。

   更多的数据，更少的存储空间

   一般来说，数据库中有两种类型的压缩：行压缩与页压缩。实际上，它们以不同的方法压缩数据，因此，很有必要理解两者的优势所在及它们的工作方式。行压缩是真正的压缩，为什么数据库引擎会删除列尾未使用的空间呢？当然这是为了节省空间。这正是SQL Server在vardecimal压缩中使用的同一技术，微软只不过把它扩展到其他数据类型上了。

   而页压缩使用的是众所皆知的字典压缩，它把每页中的数据标准化之后并保留一个查找指针。这也是Oracle Database 11g所使用的技术，只不过Oracle称之为Oracle高级压缩。在此，我们无须对两种压缩方式了解过多，但必须知道SQL Server的页压缩包括了更低级的行压缩，换句话来说，如果你打开了页压缩，就自动打开了行压缩。

   在SQL Server 2008中，微软已经包含了几个存储过程，以方便你在开始压缩之前，就可以估计使用哪种压缩方法之后，两者的节省水平，以及解压数据库之后，数据将会扩展到多大。这是一个非常重要且体贴的功能，因为你不仅需要了解是否值得花时间压缩，而且还要知道磁盘是否处理得了还原后未压缩的数据。但要紧记的是，这些存储过程是基于小范围的统计上的随机数据采样，如果碰巧遇到一个数据上的采样失误，那么就会得到错误的估计结果。

   另外，微软实现压缩的方法，节约的不仅仅是存储资源，数据还可以在内存中保持压缩状态，只在读取时才解压，这意味着你可以把更多的数据页装入内存中，由此减少磁盘读取次数，而CPU用于解压的时间，也远远少于磁盘寻道的时间。

   稀疏列允许你存储空值而无须占用物理空间，如果在一张“巨大”的表中，列有许多空值，可能会浪费大量的磁盘空间来跟踪这些空值。而把空值存储在稀疏列中则不会占用任何空间，存储需求也会随之降低。

   在使用稀疏列时要非常留意一点，它们与压缩不兼容，坦白地说，这是微软的一大失误。希望本着为用户着想的原则，在某个Service Pack中就能更正这个问题，而不是要等到下个版本。同时，如果你在表中也定义了稀疏列，那么也不要指望会压缩表中的数据，真是不知道微软是怎么搞的，这些本不应该出现在正式产品中的。如果非要说稀疏列与压缩他俩是一对完美的组合，那“如花”可能也配得上金城武了。

   压缩索引还像码事，至少名符其实，这又是节省存储空间的另一个方法。过滤索引可以在索引上放置一个where子句（如某条查询），以便只有表的一部分被索引。听上去似乎不太妥当，但在某些情况下你可能就会想要过滤某些索引了，举个例子来说，在使用稀疏列时，有了过滤索引就无须保持一个包含了主要是空值的索引，你可在稀疏列上放置一条索引，只取那些非空值就行了。这样做以后，只有那些带有实际值的行会被索引，而索引的体积也会相应大幅减小。