Search code examples
sql-serverencodingvarcharnvarchar

Why not always use nvarchar over varchar when storing data?


Im building a website that might have unicode characters in it the client hasn't specified, I want to use nvarchar as the datatype on sql server. Is there any downside to using nvarchar over varchar.

Why would anyone want to use varchar over nvarchar if nvarchar can hold more characters the varchar. Is the only downside the side to using nvarchar that the data would be greater in nvarchar then varchar?

Also can Nvarchar still store all the characters that varchar stores?


Solution

  • I think the (indirect) point you're making is that you'd almost always want to use it. In general it's best to start accepting unicode data from the outset, otherwise you end up with a legacy headache that you don't want. You'd be surprised what you can overlook in regard to expected input. And systems have a habit of becoming bigger than you expected, with the need to handle internationalised input. There are certain fields that you'll want to restrict. For example if you're storing domain names, then support across systems for multilingual characters is likely to still be unreliable (it's being worked on), so you'll want to restrict the input for things like that. In those cases you'll need to restrict the input at a higher level, for example through a regular expressions at the UI level, otherwise if you've declared a varchar field in the database you'll just end up with completely the wrong character being stored if a unicode character does manage to get through.

    Space isn't an issue these days, however there are performance considerations, although scenarios are unlikely that would outweigh the need for scalability:

    https://msdn.microsoft.com/en-us/library/ms189617.aspx

    A critical point is that you need to explicitly specify that you're using UTF-8 consistently throughout your application layers for full international support.