Escribe las diferencias entre varchar y nvarchar

Actualmente en nuestra base de datos SQL Server 2012, estamos usando varchar, y nos gustaría cambiar eso nvarchar. He generado un script para hacer eso.

Mi pregunta es ¿hay alguna diferencia en cómo SQL Server escribe en varcharcolumnas frente a nvarcharcolumnas? Tenemos varios procedimientos de backend que me preocupan.

Editar:
no estoy seguro de si esto ayuda, pero las columnas no tienen índices, f / k o restricciones en ellas.

Debe asegurarse de prefijar los literales de cadena Unicode con un prefijo N. Por ejemplo, estos funcionarán de manera diferente si el tipo de datos subyacente es 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'រៀន';

Resultados:

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

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

c
----
រៀន

Para aquellos en dispositivos móviles o navegadores decrépitos que muestran caracteres de cuadro en lugar de caracteres Unicode reales, esto es lo que parece:

La mayor preocupación es que nvarcharusa 2 bytes por carácter, mientras que varcharusa 1. Por lo tanto, nvarchar(4000)usa la misma cantidad de espacio de almacenamiento que varchar(8000)*.

Además de todos los datos de tus personajes que necesitan el doble de espacio de almacenamiento, esto también significa:

• Puede que tenga que usar nvarcharcolumnas más cortas para mantener las filas dentro del límite de la fila de 8060 bytes / límite de columna de caracteres de 8000 bytes.
• Si está utilizando nvarchar(max)columnas, se eliminarán de la fila antes de varchar(max)lo que lo haría.
• Es posible que tenga que usar nvarcharcolumnas más cortas para mantenerse dentro del límite de clave de índice de 900 bytes (no sé por qué querría utilizar una clave de índice tan grande, pero nunca se sabe).

Además de eso, trabajar con nvarcharno es muy diferente, suponiendo que el software de su cliente esté diseñado para manejar Unicode. SQL Server convertirá un varchara de nvarcharforma transparente , por lo que no necesita estrictamente el prefijo N para los literales de cadena a menos que esté usando caracteres de 2 bytes (es decir, Unicode) en el literal. Tenga en cuenta que la fundición nvarchara varbinaryrendimientos resultados diferentes haciendo lo mismo con varchar. El punto importante es que no tendrá que cambiar inmediatamente cada literal varchar a un literal nvarchar para que la aplicación funcione, lo que ayuda a facilitar el proceso.

* Si utiliza la compresión de datos (la compresión de fila ligera es suficiente, se requiere Enterprise Edition antes de SQL Server 2016 SP1 ), generalmente encontrará nchary nvarcharno ocupará más espacio que , chary varchardebido a la compresión Unicode (utilizando el algoritmo SCSU) .

Piense que las siguientes son diferencias importantes:

1. Nvarchar almacena datos UNICODE. Si tiene requisitos para almacenar UNICODE o datos multilingües, nvarchar es la opción. Varchar almacena datos ASCII y debe ser su tipo de datos de elección para el uso normal.
2. Con respecto al uso de memoria, nvarchar usa 2 bytes por carácter, mientras que varchar usa 1.
3. UNIRSE a un VARCHAR a NVARCHAR tiene un impacto considerable en el rendimiento.
4. Es posible que necesite un prefijo N cuando inserte datos: INSERT dbo.t (c) SELECT N'ʤ ʥ ʦ ʧ ʨ ';
5. Algunos expertos recomiendan nvarchar siempre porque: dado que todos los sistemas operativos y plataformas de desarrollo modernos usan Unicode internamente, el uso de nvarchar en lugar de varchar evitará la codificación de las conversiones cada vez que lea o escriba en la base de datos

Se requirió nvarchar para RDP Merge Replication de una base de datos móvil a SQL Server 2005. También LTrim (), RTrim () y Trim () se usaron mucho bc nvarchar no recortó () espacios automáticamente desde la entrada de datos, mientras que Varchar sí .

No sé si eso ha cambiado en los últimos años o no, pero nvarchar es ahora el estándar utilizado para los inicios de sesión del sitio web de membresía simple de .NET en VS Pro 2017 utilizado en la base de datos generada.

Si usa NVarchar sobre Varchar y no tiene ningún requisito para admitir MULTI-LINQUAL, aumentará el almacenamiento para DB, copias de seguridad (locales y externas). Las bases de datos modernas deben ser compatibles con ambos y cualquier impacto de conversión debe considerarse en el diseño.