length - ¿Para qué sirve realmente el tipo de datos de caracteres nacionales SQL(NCHAR)?

varchar max length sql server

Question

Además de CHAR (CHARACTER) y VARCHAR (CHARACTER VARYING) , SQL ofrece un tipo NCHAR (NATIONAL CHARACTER) y NVARCHAR (NATIONAL CHARACTER VARYING) . En algunas bases de datos, este es el mejor tipo de datos para usar para cadenas de caracteres (no binarios):

• En SQL Server, NCHAR se almacena como UTF-16LE y es la única manera de almacenar de manera confiable caracteres que no sean ASCII, siendo CHAR página de códigos de un solo byte;

• En Oracle, NVARCHAR puede almacenarse como UTF-16 o UTF-8 en lugar de una intercalación de un solo byte;

• Pero en MySQL, NVARCHAR es VARCHAR , por lo que no hace ninguna diferencia, cualquier tipo se puede almacenar con UTF-8 o cualquier otra intercalación.

Entonces, ¿qué significa realmente NATIONAL conceptualmente, si es que algo? Los documentos de los proveedores solo le informan sobre qué carácter establece el uso de su propio DBMS, en lugar del fundamento real. Mientras tanto, el estándar SQL92 explica la característica aún menos útil, indicando solo que el NATIONAL CHARACTER se almacena en un conjunto de caracteres definido por la implementación. A diferencia de un simple CHARACTER , que se almacena en un conjunto de caracteres definido por la implementación. Que podría ser un conjunto de caracteres definido por la implementación diferente. O no.

Gracias, ANSI. Thansi.

¿Debería uno usar NVARCHAR para todos los propósitos de almacenamiento de caracteres (no binarios)? ¿Hay actualmente DBMS populares en los que hará algo indeseable, o que simplemente no reconocen la palabra clave (o N'''' literales)?

Answer 1

Mientras tanto, el estándar SQL92 explica la característica aún menos útil, indicando solo que el CARÁCTER NACIONAL se almacena en un conjunto de caracteres definido por la implementación. A diferencia de un simple CARÁCTER, que se almacena en un conjunto de caracteres definido por la implementación. Que podría ser un conjunto de caracteres definido por la implementación diferente. O no.

Casualmente, esta es la misma "distinción" que establece el estándar C ++ entre char y wchar_t . Una reliquia de la codificación de la edad oscura de los caracteres cuando cada combinación de idioma / sistema operativo tiene su propio conjunto de caracteres.

¿Debería uno usar NVARCHAR para todos los propósitos de almacenamiento de caracteres (no binarios)?

No es importante si el tipo declarado de su columna es VARCHAR o NVARCHAR . Pero es importante utilizar Unicode (ya sea UTF-8, UTF-16 o UTF-32) para todos los propósitos de almacenamiento de caracteres.

¿Hay DBMS actualmente populares en los que hará algo indeseable?

Sí: en MS SQL Server, el uso de NCHAR hace que sus datos (en inglés) ocupen el doble de espacio. Desafortunadamente, UTF-8 aún no es compatible .

Answer 2

"NACIONAL" en este caso significa caracteres específicos para diferentes nacionalidades. Los idiomas del Lejano Oriente especialmente tienen tantos caracteres que un byte no es suficiente espacio para distinguirlos a todos. Por lo tanto, si tiene una aplicación en inglés (ascii) o solo en inglés , puede alejarse utilizando los tipos anteriores CHAR y VARCHAR, que solo permiten un byte por carácter.

Dicho esto, la mayoría de las veces debes usar NCHAR / NVARCHAR. Incluso si no cree que necesita admitir (o posiblemente admitir) varios idiomas en sus datos, incluso las aplicaciones solo en inglés deben ser capaces de manejar sensiblemente los ataques de seguridad utilizando caracteres en idiomas extranjeros.

En mi opinión, el único lugar donde todavía se prefieren los tipos CHAR / VARCHAR más antiguos es para los códigos internos ascii de referencia frecuente y los datos en plataformas como Sql Server que admiten la distinción, datos que serían el equivalente de una enum en un lenguaje de cliente como C ++ o C #.

Answer 3

En Oracle, el conjunto de caracteres de la base de datos puede ser un conjunto de caracteres de múltiples bytes, por lo que puede almacenar todo tipo de caracteres allí ... pero necesita comprender y definir la longitud de las columnas de manera apropiada (en BYTES o CHARACTERS) .

NVARCHAR le ofrece la opción de tener un juego de caracteres de base de datos que sea de un solo byte (lo que reduce la posibilidad de confusión entre las columnas de tamaño BYTE o CHARACTER) y utilizar NVARCHAR como el byte múltiple. Mira here .

Como trabajo predominantemente con datos en inglés, elegiría un conjunto de caracteres de varios bytes (principalmente UTF-8) como conjunto de caracteres de la base de datos e ignoraría NVARCHAR. Si heredé una base de datos anterior que estaba en un conjunto de caracteres de un solo byte y era demasiado grande para convertir, puedo usar NVARCHAR. Pero preferiría no hacerlo.