La vraie raison pour laquelle vous voulez utiliser NVARCHAR est lorsque vous avez différent langues dans la même colonne, vous devez adresser les colonnes en T-SQL sans décodage, vous souhaitez pouvoir voir les données "nativement" dans SSMS, ou vous souhaitez standardiser sur Unicode.
Si vous traitez la base de données comme un stockage muet, il est parfaitement possible de stocker des chaînes larges et des encodages différents (même de longueur variable) dans VARCHAR (par exemple UTF-8). Le problème survient lorsque vous essayez d'encoder et de décoder, en particulier si la page de code est différente pour différentes lignes. Cela signifie également que SQL Server ne sera pas en mesure de traiter facilement les données à des fins d'interrogation dans T-SQL sur des colonnes encodées (potentiellement variables).
L'utilisation de NVARCHAR évite tout cela.
Je recommanderais NVARCHAR pour toute colonne qui contiendra des données saisies par l'utilisateur qui sont relativement sans contrainte.
Je recommanderais VARCHAR pour toute colonne qui est une clé naturelle (comme une plaque d'immatriculation de véhicule, un SSN, un numéro de série, une étiquette de service, un numéro de commande, un indicatif d'aéroport, etc.) qui est généralement définie et contrainte par une norme, une législation ou une convention. Aussi VARCHAR pour l'utilisateur, et très contraint (comme un numéro de téléphone) ou un code (ACTIVE/CLOSED, Y/N, M/F, M/S/D/W, etc.). Il n'y a absolument aucune raison d'utiliser NVARCHAR pour ceux-là.
Alors pour une règle simple :
VARCHAR lorsque la contrainte est garantieNVARCHAR dans le cas contraire
