Although I agree that saving space is "a good thing" (tm), I do wonder if the full impact of this operation is considered.

As far as changing an nvarchar to a varchar where functionally possible, hurray!

As far as PAGE compression goes... hmm

=> it's nice to see I/O comes down due to the more compact storage as IO often is a bottleneck on servers. (CPU's are cheap, memory and fast disks are 'relatively spoken' not) but then again, the actual execution times go up !?

=> what happens to INSERT/UPDATE/DELETE operations ? Won't they be affected more when using PAGE compression ?

=> what happens to queries that try to fetch data from NON-indexed columns. I know doing so is "bad", but it happens all the time, either because there is some WHERE part that affects an additional (non-index-included) field, or because the WHERE messes up the search-ability by putting some function around the fields.

=> adding more (compressed) indexes to cover all fields doesn't really sound like an option either as it will make the database bigger again and probably causes lots of side-effects when making changes to the data

I guess a lot of the actual gain depends on the way the data is being used;

* functionally (eg. only access via some procedures with "restricted" (and hence known) execution plans or more of the ad-hoc type of operations),

* technically (SELECT by day, update by night or a mixed bag 24/7 ?)

* and practically (3 vs 300 concurrent users)

Simply having a slimmer database does not necessary result in a fitter database IMHO, but I agree it might... I'm merely trying to be cautious here.