Is there a reason to use NVarChar?

  • The databases all contain English data, and are not expected to contain anything but English data.

    If another language is added it will be Spanish/French and all those characters seem to be within VarChar.

    So, am I missing something?

    (Besides the obvious ability to input Japanese/Chinese/Farsi/Arabic/etc.)

    I know that starting in Visual Basic 6 there was an "all DBCS" internal representation so I'm allowing for the fact that I might be missing something.

    I happen to be using SQL Server 2005, but we are moving to 2008-R2 so if there's an answer specific to 64-bit machines that would very helpful.

    (And searching "NVarChar" brings back a lot of results, so I apologize if there's a post I didn't see)

    -Chris C.

  • As soon as you leave the base 256 character set of any language, you'll need nVarchar. You've got the jist of the difference. Under most circumstances most english speaking companies will not require this.


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • I'm torn with nvarchar. The idealist in me loves the idea of a single unified character set, but the side of me that loves performance refuses to waste space for values that don't need it and can be represented by a varchar.

    If row compression could handle this, it would be the best of both worlds!

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

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