Many of my databases have fields defined as varchars. This hasn't been much of problem since I live and work in America (where the only language that exists is "American". ahem)
After working with databases for about 5 years, I've found I eventually run into problems with the limited nature of the varchar field and I have to modify my fields to store data as nvarchars. After having to make another update to a table, converting a varchar field to an nvarchar, I just had the thought– why are we still doing it this way? I've long since made the mental decision to define all of new my text fields to nvarchar, instead of varchar, which is what I learned to do from my text books when I was in school 10 years ago.
It's 2011 and there was a new release of SQL Server last year. Why do we continue to support a varchar datatype when we can/should instead be using nvarchar?
I know that it is often argued that nvarchars are "twice as large" as varchars, so storage space usage could be one arguement for maitaining varcars.
However, today's users could define their nvarchars to store the data as UTF-8 instead of the default UTF-16 if they want to save on storage space. This would allow for 8-bit encoding if that is primarily desirable, while giving assurance that the rare 2-8 byte character that gets inserted into their DB would't break anything.
Am I missing something? Is there a good reason why this hasn't changed over the past 15-20 years?
Best Answer
varchar work is good enough for a lot of Western European languages (Norwegian, Danish, German, French, Dutch etc too) subject to some collation issues
See this on SO varchar vs nvarchar performance nvarchar has serious performance implications
This is trivial compared to dealing with dates MDY vs DMY