Sure. I use CHAR. It's all a part of right-sizing data. Such right sizing does some incredible things, not the least of which is preventing the massive page splits and the resulting fragmentation in columns that are first inserted and then "ExpAnsively" updated, like that wonderful "Modified_By" column that a lot of people include in their tables. Of course, there is a trade-off and you don't want to use a CHAR(50) (for example) on something that's only populated something like 10% of the time. AND, of course, that's also where data-normalization or Fill Factors with proper index maintenance comes into play.
Heh... some folks raise hell about the use of CHAR() but think nothing of wasting huge amounts of space with NULL VARCHAR()s.
Uh... what's that you say? NULL VARCHARs use no space??? Yeah... a whole lot of people think they know that. Do an experiment. Create a table with an Identity or other populated column as the first column in a Clustered Table and have 10 NULL VARCHAR(10) columns to the right of that. Populate that first column for several rows. Just that column. Nothing else yet. Let all those VARCHAR columns be NULL. Then, Use sys.dm_db_index_physical_stats to see the min, avg, and max row sizes .
Once you have those 3 values written down, add just one byte to the VARCHAR column furthest to the right in the Clustered Table. Everyone knows that column will now occupy just 3 bytes... 1 for the character and 2 for the length (which is actually incorrect but still has 2 bytes), right? And the total row length will only grow by 3, RIGHT?
Let's see if that's true... do another sys.dm_db_index_physical_stats and measure what you measured before. Did the min, max, and average only increase by the 3 bytes caused by adding a single byte to the right most column?
Now, ask yourself about the "poor man's" auditing that you build into a lot of your tables and where the "Created_By" column normally shows up in the table.
Surprise, surprise, SURPRISE! 😀
More to come on that subject.