Chaque ingénieur définissant une nouvelle colonne de chaîne décide : dois-je utiliser nvarchar ou varchar ?
Depuis que j’ai découvert nvarchar, j’utilise toujours nvarchar. Mon raisonnement est : pourquoi utiliser un type de données qui pourrait ne pas supporter une valeur de texte, et vous ne découvrirez probablement une incompatibilité que lorsqu’elle sera en production.
J’entends l’argument sur l’espace, mais l’espace est bon marché et ne vaut pas la peine de s’en préoccuper. 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 en espace de varchar (1).
Une autre chose à considérer est que 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-ish)
Cette réponse Stack Overflow résume nvarchar vs. varchar :
Une colonne nvarchar peut stocker n’importe quelles données Unicode. Une colonne varchar est limitée à une page de codes 8 bits. Certaines personnes pensent que varchar devrait être utilisé parce qu’il prend moins de place. Je crois que ce n’est pas la bonne réponse. Les incompatibilités de pages de codes sont pénibles, et Unicode est la solution 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 et plates-formes de développement modernes 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 après des erreurs de conversion est un problème non trivial.
Si vous interfacez avec une application qui n’utilise que l’ASCII, je recommanderais quand même d’utiliser Unicode dans la base de données. Les algorithmes de classement du système d’exploitation et de la base de données fonctionneront mieux avec Unicode. Unicode évite les problèmes de conversion lors de l’interfaçage avec d’autres systèmes. Et vous vous préparerez pour l’avenir. Et vous pouvez toujours valider que vos données sont limitées à l’ASCII 7 bits pour tout système hérité que vous devez maintenir, tout en bénéficiant de certains avantages du stockage Unicode complet. (2)
Ma conclusion est que la seule fois où les données sont un varchar, c’est quand elles sont au repos.
Références :
1. Implémentation de la compression Unicode
2. Quelle est la différence entre varchar et nvarchar ?
Auteur : Chuck Conway est un ingénieur IA avec près de 30 ans d’expérience en génie logiciel. Il construit des systèmes IA pratiques — pipelines de contenu, agents d’infrastructure et outils qui résolvent des problèmes réels — et partage ce qu’il apprend en chemin. Connectez-vous avec lui sur les réseaux sociaux : X (@chuckconway) ou visitez-le sur YouTube et sur SubStack.