SQL: VARCHAR vs NVARCHAR

 SQL: VARCHAR vs NVARCHAR

Reference 1

Reference 2

varchar is used for non-Unicode characters only on the other hand nvarchar is used for both unicode and non-unicode characters. Some other difference between them is given below.

VARCHAR vs. NVARCHAR

	VARCHAR	NVARCHAR
Character Data Type	Variable-length, non-Unicode characters	Variable-length, both Unicode and non-Unicode characters such as Japanese, Korean, and Chinese.
Maximum Length	Up to 8,000 characters	Up to 4,000 characters
Character Size	Takes up 1 byte per character	Takes up 2 bytes per Unicode/Non-Unicode character
Storage Size	Actual Length (in bytes)	2 times Actual Length (in bytes)
Usage	Used when data length is variable or variable length columns and if actual data is always way less than capacity	Due to storage only, used only if you need Unicode support such as the Japanese Kanji or Korean Hangul characters.

• Fields for Student and/or Faculty names should probably be NVARCHAR since, over time, it is only getting more likely that names from other cultures will be showing up in those places.

• But for street address and city names? The purpose of the app was not stated (it would have been helpful) but assuming the address records, if any, pertain to just to a particular geographical region (i.e. a single language / culture), then use VARCHAR with the appropriate Code Page (which is determined from the Collation of the field).

• If storing State and/or Country ISO codes (no need to store INT / TINYINT since ISO codes are fixed length, human-readable, and well, standard :) use CHAR(2) for two-letter codes and CHAR(3) if using 3 letter codes. And consider using a binary Collation such as Latin1_General_100_BIN2.

• If storing postal codes (i.e. zip codes), use VARCHAR since it is an international standard to never use any letter outside of A-Z. And yes, still use VARCHAR even if only storing US zip codes and not INT since zip codes are not numbers, they are strings, and some of them have a leading "0". And consider using a binary Collation such as Latin1_General_100_BIN2.

• If storing email addresses and/or URLs, use NVARCHAR since both of those can now contain Unicode characters.

• and so on....