john.arnott (10/16/2009)
Tom Garth (10/16/2009)
.....I get the feeling that John derived this question from a real world application rather than just for kicks.Actually, yes. I've been going through a database structure provided by a vendor that sells their software globally. We use it only in the USA with English, and we've found that we would be able to cut the size of our databases by a substantial amount by changing many of the nchar() columns to varchar(). There are a few of those columns that vary in length, but only slightly, and use most of the vendor-allocated column length, so they will be changed from nchar() to char(), and not varchar().
This is largely off topic but I found this post interesting.
Just out of curiosity, do you need to cut the size of your database substantially or does it just offend you that so much space is theoretically wasted? I can't help but wonder if the cost of changing the data types can be recovered by the savings gleaned from shrinking your databases? (Since the cost of storage is significantly less than a dollar a GB you'll need some pretty serious space savings to make it worth your while.) While it's true you might be able to fit a few more rows on each page, quantifying performance gains gleaned from shrinking the database is a little harder to do but is almost certainly measured in microseconds and the loss of scalability into foreign markets is a fairly significant trade off.
I don't know whether you've done this or not but storing your data in unicode (as English) and then displaying it in your apps using another language is really pretty easy but if your data isn't in unicode you're seriously screwed should that requirement suddenly surface. The world is flat and unicode is a fairly insignificant cost of doing business. Clearly, your vendor understands this.
"Beliefs" get in the way of learning.