NVarchar Vs Varchar

Chaque ingénieur définissant une nouvelle colonne de chaîne décide : Est-ce que j’utilise nvarchar ou est-ce que j’utilise varchar ?

Depuis que j’ai découvert nvarchar, j’ai toujours utilisé nvarchar. Ma réflexion est : pourquoi utiliser un type de données qui pourrait ne pas supporter une valeur de texte, et vous ne découvrirez probablement une valeur incompatible qu’une fois en production.

J’entends l’argument concernant l’espace, mais l’espace est bon marché et ne vaut pas la peine de s’en inquiéter. Je sais ce que vous pensez, le coût n’a pas d’importance quand le disque dur est plein, et je suis d’accord.

À partir de Sql Server 2008 R2, la compression de données est appliquée aux champs nchar et nvarchar (nvarchar(max) est exclu). Selon les données, l’efficacité de la compression varie, mais avec l’anglais, il y a une compression de 50%, ce qui la met au même niveau que les besoins d’espace de varchar (1).

Autre chose à considérer : la plupart des langages de programmation supportent UTF-16 comme type de chaîne. Donc chaque fois qu’un varchar est chargé depuis la base de données, il est converti en UTF-16 (nvarchar-esque)

Cette réponse StackOverflow résume nvarchar vs. varchar :

Une colonne nvarchar peut stocker n’importe quelle donnée Unicode. Une colonne varchar est restreinte à une page de codes 8-bit. Certaines personnes pensent que varchar devrait être utilisé parce qu’il prend moins d’espace. Je crois que ce n’est pas la bonne réponse. Les incompatibilités de pages de codes sont pénibles, et Unicode est le remède aux problèmes de pages de codes. Avec les disques et la mémoire bon marché de nos jours, il n’y a vraiment aucune raison de perdre du temps à bricoler avec les pages de codes.

Tous les systèmes d’exploitation modernes et les plateformes de développement utilisent Unicode en interne. En utilisant nvarchar plutôt que varchar, vous pouvez éviter de faire des conversions d’encodage chaque fois que vous lisez ou écrivez dans la base de données. Les conversions prennent du temps, et sont sujettes aux erreurs. Et la récupération des erreurs de conversion est un problème non trivial.

Si vous interfacez avec une application qui utilise seulement ASCII, je recommanderais quand même d’utiliser Unicode dans la base de données. Les algorithmes de collation de l’OS et de la base de données fonctionneront mieux avec Unicode. Unicode évite les problèmes de conversion lors de l’interface avec d’autres systèmes. Et vous vous préparerez pour l’avenir. Et vous pouvez toujours valider que vos données sont restreintes à l’ASCII 7-bit pour quel que soit le système legacy que vous devez maintenir, tout en profitant de certains des avantages du stockage Unicode complet. (2)

Ma conclusion est que la seule fois où les données sont en varchar, c’est quand elles sont au repos.

Références :

1. Unicode Compression implementation
2. What is the difference between varchar and nvarchar?