Истинската причина, поради която искате да използвате NVARCHAR, е, когато имате различно езици в една и съща колона, трябва да адресирате колоните в T-SQL без декодиране, искате да можете да виждате данните „нативно“ в SSMS или искате да стандартизирате в Unicode.
Ако третирате базата данни като глупаво хранилище, е напълно възможно да съхранявате широки низове и различни (дори с променлива дължина) кодиране във VARCHAR (например UTF-8). Проблемът идва, когато се опитвате да кодирате и декодирате, особено ако кодовата страница е различна за различните редове. Това също така означава, че SQL Server няма да може да се справя лесно с данните за целите на запитване в T-SQL на (потенциално променливо) кодирани колони.
Използването на NVARCHAR избягва всичко това.
Бих препоръчал NVARCHAR за всяка колона, в която ще има въведени от потребителя данни, които са относително неограничени.
Бих препоръчал VARCHAR за всяка колона, която е естествен ключ (като регистрационна табела на превозно средство, SSN, сериен номер, сервизен етикет, номер на поръчка, позивна на летището и т.н.), която обикновено е дефинирана и ограничена от стандарт или законодателство или конвенция. Също така VARCHAR за въведени от потребителя и много ограничени (като телефонен номер) или код (АКТИВЕН/ЗАТВОРЕН, Y/N, M/F, M/S/D/W и т.н.). Няма абсолютно никаква причина да използвате NVARCHAR за тях.
И така, за едно просто правило:
VARCHAR, когато е гарантирано, че е ограниченNVARCHAR в противен случай
