To NVarChar or not to NVarChar

  • Just wondering if someone with knowledge out there can confirm to me if nvarchar's are worth using if there's little chance of the application ever being used in a non-english environment?

    I was led to believe that using unicode was an easier ride for the developers in the long run, but having looked into it, I can only see that nvarchars are just going to use double the space of their varchar counterparts. The database is highly unlikeable to be used in any language requiring the extra bits to cover additional language symbols.

    So can someone confirm if my thinking is right. Thanks.

  • I never use Nvarchar unless needed. The application people probably won't know the difference. I have converted from Nvarchar to VarChar and never heard a word.

    KlK, MCSE


    KlK

  • Agree. Don't use NCHAR or NVARCHAR unless you are absolutely positive that you require a wide character set. Many folks often are misguided into thinking that characters that actually fall in the ASCII character set (VARCHAR) require NVARCHAR to display. It's not really the Non-English world that's the problem, since most Western and European languages actually fit in the ASCII character set. Only non-alphabetic languages (e.g. symbol languages) will require NVARCHAR (unicode) sets.

  • And if you choose to use nvarchar, be extremely careful with data types mixing and matching. We use nvarchar for some columns as we anticipate porting parts of our application to Chinese. I've recently tuned an extremely slow performing query. Execution plan exposed an additional implicit conversion. Turned out to be "WHERE" clause contained varchar and nvarchar columns comparison. Made them both varchar and exec time dropped from almost 2 minutes to under a second.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply