Écrire les différences entre varchar et nvarchar

Nous utilisons actuellement dans notre base de données SQL Server 2012 varchar, et nous aimerions changer cela nvarchar. J'ai généré un script pour le faire.

Ma question est la suivante: existe-t-il des différences dans la façon dont SQL Server écrit en varcharcolonnes par rapport aux nvarcharcolonnes? Je suis préoccupé par un certain nombre de procédures d’arrière-plan.

Edit: Vous
ne savez pas si cela vous aidera, mais les colonnes ne sont pas indexées, ni f / k, ni contraintes.

Vous devez être sûr que vous préfixez les littéraux de chaîne Unicode avec un préfixe N. Par exemple, ceux-ci fonctionneront différemment si le type de données sous-jacent est NVARCHAR:

CREATE TABLE dbo.t(c NVARCHAR(32));

INSERT dbo.t(c) SELECT 'រៀន';
INSERT dbo.t(c) SELECT 'នរៀ';
INSERT dbo.t(c) SELECT N'រៀន';

SELECT c FROM dbo.t;

SELECT c FROM dbo.t WHERE c = 'រៀន';
SELECT c FROM dbo.t WHERE c = N'រៀន';

Résultats:

c
----
??? -- not stored correctly
??? -- not stored correctly
រៀន -- stored correctly!

c
----
???
??? -- probably not expected, however all Unicode characters have been changed to ?

c
----
រៀន

Pour les utilisateurs d'appareils mobiles ou les navigateurs décrépis qui affichent des caractères de boîte au lieu de caractères Unicode, voici à quoi ça ressemble:

La principale préoccupation concerne l' nvarcharutilisation de 2 octets par caractère, alors que la valeur varchar1. nvarchar(4000)utilise la même quantité d'espace de stockage que varchar(8000)*.

En plus de toutes vos données de personnage nécessitant deux fois plus d'espace de stockage, cela signifie également:

• Vous devrez peut-être utiliser des nvarcharcolonnes plus courtes pour conserver les lignes dans la limite de 8060 octets de lignes / 8 000 caractères.
• Si vous utilisez des nvarchar(max)colonnes, elles seront déplacées plus rapidement que prévu varchar(max).
• Vous devrez peut-être utiliser des nvarcharcolonnes plus courtes pour rester dans la limite de clé d'index de 900 octets (je ne sais pas pourquoi vous voudriez utiliser une clé d'index de cette taille, mais vous ne le savez jamais).

En outre, travailler avec nvarcharn'est pas très différent, en supposant que votre logiciel client est conçu pour gérer Unicode. SQL Server convertira de manière transparente un élément varcharen nvarchar, vous n'avez donc pas strictement besoin du préfixe N pour les littéraux de chaîne, sauf si vous utilisez des caractères à 2 octets (c.-à-d. Unicode) dans le littéral. Sachez que la coulée nvarcharde varbinaryrendements différents résultats que de faire la même chose avec varchar. Le point important est que vous n’aurez pas à changer immédiatement chaque littéral varchar en nvarchar pour que l’application continue de fonctionner, ce qui facilite le processus.

* Si vous utilisez la compression de données (la compression assez légère de ligne est, Enterprise Edition requise avant SQL Server 2016 SP1 ) vous trouverez généralement ncharet nvarcharprendre plus d' espace que charet varchar, en raison de la compression Unicode ( en utilisant l'algorithme SDU) .

Pensez aux différences majeures suivantes:

1. Nvarchar stocke les données UNICODE. Si vous avez besoin de stocker des données UNICODE ou multilingues, choisissez nvarchar. Varchar stocke les données ASCII et devrait être votre type de données de choix pour une utilisation normale.
2. En ce qui concerne l'utilisation de la mémoire, nvarchar utilise 2 octets par caractère, alors que varchar en utilise 1.
3. La jonction d’un VARCHAR à NVARCHAR a un impact considérable sur les performances.
4. Peut nécessiter un préfixe N lors de l'insertion de données: INSERT dbo.t (c) SELECT N'ʤ ʦ ';
5. Certains experts recommandent toujours nvarchar car, dans la mesure où tous les systèmes d'exploitation et plateformes de développement modernes utilisent Unicode en interne, utiliser nvarchar plutôt que varchar permet d'éviter les conversions de codage à chaque lecture ou écriture dans la base de données.

nvarchar était requis pour la réplication de fusion RDP depuis une base de données mobile vers SQL Server 2005. De plus, LTrim (), RTrim () et Trim () étaient beaucoup utilisés, car nvarchar ne supprimait pas automatiquement les espaces de saisie des .

Je ne sais pas si cela a changé ces dernières années ou non, mais nvarchar est maintenant la norme utilisée pour les connexions au site Web .NET Simple Membership sur VS Pro 2017 utilisées dans la base de données générée.

Si vous utilisez NVarchar sur Varchar et que vous n'êtes pas obligé de prendre en charge MULTI-LINQUAL, vous augmentez le stockage pour la base de données et les sauvegardes (locales et hors site). Les bases de données modernes doivent prendre en charge les deux et tous les succès de conversion doivent être pris en compte dans la conception.