Is there a reason why I should not use NVARCHAR on Sql Server?

Question

I am developing a database schema right now, and I believe that I should be safe. I have to use nvarchar for text column data types (to support Unicode). Although I do not expect a non-English text, I think it would be better to support it from the very beginning just in case.

Is there a reason why I should stick with a simple cook? Performance?

Answer 1

In today's i18n world, nvarchar makes a lot of sense. varchar may make sense for data that is not non-unicode (maybe you have some system fields that are required for ASCII).

I use nvarchar by default for things like names, descriptions, addresses, etc.

varchar smaller, so there is probably an IO savings with varchar over nvarchar (but note that the codepage is also becoming a big problem).

Answer 2

Also see this question: VARCHAR versus NVARCHAR performance.

Personally, I say stick with varchar (as I answered in this thread). There is non-trivial overhead.

Answer 3

Yes, performance, in size. nvarchar accepts more bytes, I think it doubles (correct me if I am wrong) and this is due to unicode support. Therefore, if you do not need unicode support, go with regular varchar.

Answer 4

We use VARCHAR for almost everyone, and NVARCHAR is very rare.

NVarchar does not need the product code - we do not allow anything in them except AZ, 0-9 and "_" ...

Two times more storage space, but also has only half the entries on the index page (and data page), and half the memory cache is wasted, there are more CPU cycles to compare data, etc.

IME commonly used foreign accents only work in Varchar (i.e. LATIN-1). We have no plans to make Chinese or other alternative character sets, and when we can deal with this character set using NVarchar from the first day, we will be least worried - text alignment from right to left or vertical ?: (

And if you enable NVarchar, say, a name, how are you going to enter the extended charcater from the keyboard? And if you import data (as it is already NVarchar), how can you search for this client using the standard QWERTY keyboard. There are many, many things related to the internationalization of the application, so I believe that it makes no sense to "resolve this using NVarchar."

But again, there are many places where I go to have NVarchar ... and most columns also have a width of 50 characters ... they should know something about population growth plans and expanding zip code plans that I don't know!

Answer 5

As already mentioned, compromise is the future protection against performance. In my experience, SQL Server does a pretty good job of lowering CPU and memory limits, but gives it slow disk I / O, and it really can intercept.

If you don't have plans for double-byte character sets (e.g. Chinese characters), stick with VARCHAR (MAX).

Answer 6

Generally speaking; Start with the most expensive data type, which has the least restrictions. Put it in production. If performance starts to be a problem, find out what nvarchar actually stores in these columns. Are there any characters who would not fit in the cook? If not, switch to varchar. Do not try to optimize before you know where the pain is. I assume that choosing between nvarchar / varchar is not something that will slow down your application in the predictable future. There will be other parts of the application where performance tuning will give you much more bang for your buck.