Is VARCHAR like totally 1990s? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

1. VARCHAR does not store Unicode characters.
2. NVARCHAR does store Unicode characters.
3. Today's applications should always be Unicode compatible.
4. NVARCHAR takes twice the amount of space to store it.
5. Point 4 doesn't matter because storage space is extremely inexpensive.

Ergo: When designing SQL Server databases today, one should always use NVARCHAR.

Is this sound reasoning? Does anyone disagree with any of the premises? Are there any reasons to choose VARCHAR over NVARCHAR today?

Answer 1

I have seen nvarchar columns converted to varchar for two reasons:

1. Application is using MSSQL Express Edition, which has 4GB database size limit. Switching to MSSQL Standard Edition would be too expensive if there are many database deployments, as would be in single-tenant webapps or applications with embedded DBMS. The cheaper SQL2008 Web Edition could help here.

2. nvarchar(4000) is not enough but you don't want an ntext column. So you convert to varchar(8000). However, in most cases you probably should convert to nvarchar(max).

Answer 2

I'd say that there are still valid reasons to not use nvarchar.

• Storage space is at a premium, such as on a shared host or the database is really huge.
• Performance is critical.
• Brownfield development (i.e. the database has existing tables that use varchar).
• You are integrating with another older system that only understands single byte characters and/or varchar.

However new development should probably use nvarchar esp. since 64-bit systems are becoming the norm. Also, companies (even small ones) are now more commonly global.