¿Cuál es la diferencia entre varchar y nvarchar?

https://stackoverflow.com/questions/144283

02-07-2019
|

Pregunta

¿Es solo que nvarchar admite caracteres multibyte? Si ese es el caso, ¿hay realmente algún otro punto, aparte de los problemas de almacenamiento, para usar varchars ?

Solución

Una columna nvarchar puede almacenar cualquier dato Unicode. Una columna varchar está restringida a una página de códigos de 8 bits. Algunas personas piensan que se debe utilizar varchar porque ocupa menos espacio. Creo que esta no es la respuesta correcta. Las incompatibilidades de la página de códigos son un dolor, y Unicode es la cura para los problemas de la página de códigos. Hoy en día, con el disco y la memoria baratos, realmente no hay razón para perder el tiempo metiéndose con las páginas de códigos.

Todos los sistemas operativos modernos y plataformas de desarrollo utilizan Unicode internamente. Al utilizar nvarchar en lugar de varchar , puede evitar realizar conversiones de codificación cada vez que lea o escriba en la base de datos. Las conversiones toman tiempo y son propensas a errores. Y la recuperación de los errores de conversión es un problema no trivial.

Si está interactuando con una aplicación que utiliza solo ASCII, recomendaría el uso de Unicode en la base de datos. Los algoritmos de intercalación de la base de datos y el sistema operativo funcionarán mejor con Unicode. Unicode evita problemas de conversión al interactuar con otros sistemas. Y te estarás preparando para el futuro. Y siempre puede validar que sus datos están restringidos a ASCII de 7 bits para cualquier sistema heredado que tenga que mantener, incluso mientras disfruta de algunos de los beneficios del almacenamiento Unicode completo.

Otros consejos

varchar : de longitud variable , datos de caracteres no Unicode. La recopilación de la base de datos determina en qué página de códigos se almacenan los datos.

nvarchar : de longitud variable Datos de caracteres Unicode. Dependiendo de la compilación de la base de datos para las comparaciones.

Con este conocimiento, utilice el que coincida con sus datos de entrada (ASCII v. Unicode).

Siempre uso nvarchar, ya que permite que cualquier cosa que esté construyendo resista casi todos los datos que le ofrezco. Mi sistema CMS hace chino por accidente, porque usé nvarchar. En estos días, cualquier aplicación nueva no debería preocuparse por la cantidad de espacio requerido.

Depende de cómo se instaló Oracle. Durante el proceso de instalación, se establece la opción NLS_CHARACTERSET. Puede encontrarlo con la consulta SELECT value $ FROM sys.props $ WHERE name = 'NLS_CHARACTERSET' .

Si su NLS_CHARACTERSET es una codificación Unicode como UTF8, genial. Usar VARCHAR y NVARCHAR son prácticamente idénticos. Deja de leer ahora, solo ve por ello. De lo contrario, o si no tiene control sobre el conjunto de caracteres de Oracle, siga leyendo.

VARCHAR & # 8212; Los datos se almacenan en la codificación NLS_CHARACTERSET. Si hay otras instancias de base de datos en el mismo servidor, es posible que estén restringidas por ellas; y viceversa, ya que tienes que compartir el escenario. Un campo de este tipo puede almacenar cualquier información que pueda codificarse utilizando ese conjunto de caracteres, y nada más . Entonces, por ejemplo, si el conjunto de caracteres es MS-1252, solo puede almacenar caracteres como letras en inglés, un puñado de letras con acento y otras (como & # 8364; y & # 8212;). Su aplicación sería útil solo para algunos entornos locales, incapaz de operar en cualquier otro lugar del mundo. Por esta razón, se considera una mala idea.

NVARCHAR & # 8212; Los datos se almacenan en una codificación Unicode. Todos los idiomas son compatibles. Una buena idea.

¿Qué pasa con el espacio de almacenamiento? VARCHAR es generalmente eficiente, ya que el conjunto de caracteres / codificación fue diseñado de forma personalizada para una configuración regional específica. Los campos de NVARCHAR se almacenan en codificación UTF-8 o UTF-16, con base en la configuración NLS de forma irónica. UTF-8 es muy eficiente para " Western " idiomas, sin dejar de soportar idiomas asiáticos. UTF-16 es muy eficiente para los idiomas asiáticos, a la vez que soporta " Western " idiomas Si le preocupa el espacio de almacenamiento, elija una configuración NLS para hacer que Oracle use UTF-8 o UTF-16 según corresponda.

¿Qué pasa con la velocidad de procesamiento? La mayoría de las nuevas plataformas de codificación utilizan Unicode de forma nativa (¡Java, .NET, incluso C ++ std :: wstring de hace años!) Por lo que si el campo de la base de datos es VARCHAR, obliga a Oracle a convertir entre conjuntos de caracteres en cada lectura o escritura, no tan bueno. El uso de NVARCHAR evita la conversión.

Línea inferior: ¡Use NVARCHAR! Evita las limitaciones y dependencias, está bien para el espacio de almacenamiento y, por lo general, también lo es para el rendimiento.

nvarchar almacena datos como Unicode, por lo tanto, si va a almacenar datos multilingües (más de un idioma) en una columna de datos, necesita la variante N.

Mis dos centavos

Los índices pueden fallar cuando no se usan los tipos de datos correctos:
En SQL & nbsp; Servidor: cuando tiene un índice sobre una columna VARCHAR y lo presenta como Cadena Unicode, SQL & nbsp; El servidor no hace uso del índice. Lo mismo sucede cuando presenta un BigInt a una columna indexada que contiene SmallInt. Incluso si BigInt es lo suficientemente pequeño como para ser SmallInt, SQL & nbsp; Server no puede usar el índice. Al revés, no tiene este problema (al proporcionar SmallInt o Ansi-Code a una columna indexada de BigInt o NVARCHAR).
Los tipos de datos pueden variar entre diferentes DBMS (DataBase Management System):
Sepa que cada base de datos tiene tipos de datos ligeramente diferentes y VARCHAR no significa lo mismo en todas partes. Mientras que SQL & nbsp; Server tiene VARCHAR y NVARCHAR, una base de datos de Apache / Derby solo tiene VARCHAR y allí VARCHAR está en Unicode.

Principalmente nvarchar almacena caracteres Unicode y varchar almacena caracteres no Unicode.

" Unicodes " significa un esquema de codificación de caracteres de 16 bits que permite que los caracteres de muchos otros idiomas como el árabe, hebreo, chino, japonés, se codifiquen en un solo conjunto de caracteres.

Eso significa que Unicodes está usando 2 bytes por carácter para almacenar y Nonunicodes usa solo un byte por carácter para almacenar. Lo que significa que Unicodes necesita una doble capacidad de almacenamiento en comparación con los que no son Unicodes.

Tienes razón. nvarchar almacena datos Unicode mientras que varchar almacena datos de caracteres de un solo byte. Aparte de las diferencias de almacenamiento ( nvarchar requiere el doble de espacio de almacenamiento que varchar ), que ya mencionó, la razón principal para preferir nvarchar sobre varchar sería la internacionalización (es decir, almacenar cadenas en otros idiomas).

Yo diría, depende.

Si desarrolla una aplicación de escritorio, donde el sistema operativo funciona en Unicode (como en todos los sistemas Windows actuales) y el idioma es compatible de forma nativa con Unicode (las cadenas predeterminadas son Unicode, como en Java o C #), luego vaya a nvarchar.

Si desarrolla una aplicación web, donde las cadenas vienen como UTF-8, y el lenguaje es PHP, que aún no admite Unicode de forma nativa (en las versiones 5.x), entonces varchar probablemente será una mejor opción.

nVarchar te ayudará a almacenar caracteres Unicode. Es el camino a seguir si desea almacenar datos localizados.

Si se utiliza un solo byte para almacenar un carácter, hay 256 combinaciones posibles y, por lo tanto, puede guardar 256 caracteres diferentes. La recopilación es el patrón que define los caracteres y las reglas por las que se comparan y ordenan.

1252, que es el Latin1 (ANSI), es el más común. Los conjuntos de caracteres de un solo byte también son inadecuados para almacenar todos los caracteres utilizados por muchos idiomas. Por ejemplo, algunos idiomas asiáticos tienen miles de caracteres, por lo que deben usar dos bytes por carácter.

Unicode standard

Cuando los sistemas que utilizan varias páginas de códigos se utilizan en una red, resulta difícil administrar la comunicación. Para estandarizar las cosas, el consorcio ISO y Unicode introdujeron el Unicode . Unicode utiliza dos bytes para almacenar cada carácter. Es decir, se pueden definir 65,536 caracteres diferentes, por lo que casi todos los caracteres se pueden cubrir con Unicode. Si dos computadoras usan Unicode, todos los símbolos se representarán de la misma manera y no se necesita conversión, esta es la idea detrás de Unicode.

SQL Server tiene dos categorías de tipos de datos de caracteres:

no Unicode (char, varchar y texto)
Unicode (nchar, nvarchar y ntext)

Si necesitamos guardar datos de caracteres de varios países, utilice siempre Unicode.

Aunque NVARCHAR almacena Unicode, debe considerar que con la ayuda de la recopilación también puede usar VARCHAR y guardar sus datos de sus idiomas locales.

Imagínate el siguiente escenario.

La intercalación de su base de datos es persa y usted guarda un valor como '???' (escritura persa de Ali) en el tipo de datos VARCHAR (10) . No hay problema y el DBMS solo usa tres bytes para almacenarlo.

Sin embargo, si desea transferir sus datos a otra base de datos y ver el resultado correcto, su base de datos de destino debe tener la misma recopilación que el objetivo que es persa en este ejemplo.

Si su clasificación de destino es diferente, verá algunos signos de interrogación (?) en la base de datos de destino.

Finalmente, recuerde que si está utilizando una gran base de datos para el uso de su idioma local, le recomendaría usar la ubicación en lugar de usar demasiados espacios.

Creo que el diseño puede ser diferente. Depende del entorno en el que trabajes.

Tengo que decir aquí (¡me doy cuenta de que probablemente me abriré a una trampa!), pero seguramente la única vez que NVARCHAR sea en realidad más útil (¡observe que más allí!) que VARCHAR es cuando todas las intercalaciones en todos los sistemas dependientes y dentro de la base de datos son iguales ...? De lo contrario, la conversión de intercalación debe realizarse de todos modos y, por lo tanto, hace que VARCHAR sea tan viable como NVARCHAR .

Para agregar a esto, algunos sistemas de bases de datos, como SQL Server (antes de 2012) tienen un tamaño de página de aprox. 8K. Entonces, si está buscando almacenar datos de búsqueda que no se encuentran en un campo como TEXT o NTEXT , entonces VARCHAR proporciona el valor total de 8k espacio mientras que NVARCHAR solo proporciona 4k (doble bytes, doble espacio).

Supongo que, para resumir, el uso de cualquiera depende de:

Proyecto o contexto
Infraestructura
Sistema de base de datos

Siga Diferencia entre Sql Server VARCHAR y Tipo de datos NVARCHAR . Aquí puedes ver de una manera muy descriptiva.

En generalnvarchar almacena los datos como Unicode, por lo tanto, si va a almacenar datos multilingües (más de un idioma) en una columna de datos, necesita la variante N.

Eché un vistazo a las respuestas y muchos parecen recomendar el uso de nvarchar sobre varchar , porque el espacio ya no es un problema, por lo que no hay ningún problema en habilitar Unicode para poco almacenamiento extra. Bueno, esto no siempre es cierto cuando desea aplicar un índice sobre su columna. SQL Server tiene un límite de 900 bytes en el tamaño del campo que puede indexar. Por lo tanto, si tiene un varchar (900) todavía puede indexarlo, pero no varchar (901) . Con nvarchar , el número de caracteres se reduce a la mitad, por lo que puede indexar hasta nvarchar (450) . Entonces, si está seguro de que no necesita nvarchar , no recomiendo usarlo.

En general, en las bases de datos, recomiendo mantener el tamaño que necesita, porque siempre puede expandir. Por ejemplo, un colega en el trabajo una vez pensó que no hay ningún daño en el uso de nvarchar (max) para una columna, ya que no tenemos ningún problema con el almacenamiento. Más adelante, cuando intentamos aplicar un índice sobre esta columna, SQL Server rechazó esto. Sin embargo, si comenzó con incluso varchar (5) , podríamos haberlo expandido más tarde a lo que necesitamos sin un problema que nos obligue a realizar un plan de migración de campo para solucionar este problema.

La diferencia principal entre Varchar (n) y nvarchar (n) es:

El tamaño de

Varchar (datos de caracteres de longitud variable, que no son Unicode) es de hasta 8000. 1.Es un tipo de datos de longitud variable

Se usa para almacenar caracteres no Unicode
Ocupa 1 byte de espacio para cada personaje

Nvarchar : datos de caracteres Unicode de longitud variable.

1.Es un tipo de datos de longitud variable

2.Utilizado para almacenar caracteres Unicode.

Los datos se almacenan en una codificación Unicode. Cada el idioma es compatible (por ejemplo, los idiomas árabe, alemán, hindi, etc., etc.)

Jeffrey L Whitledge con ~ 47000 puntuación de reputación recomienda el uso de nvarchar

Solomon Rutzky con un puntaje de reputación de ~ 33200 recomienda: NO utilice siempre NVARCHAR. Esa es una actitud / enfoque muy peligroso y, a menudo, costoso.

¿Cuáles son los principales resultados? ¿Diferencias entre los tipos de datos varchar y nvarchar de SQL Server?

https://www.sqlservercentral.com/articles/disk -es-barato-orly-4

Ambas personas de tan alta reputación, ¿qué elige un desarrollador de base de datos de servidor sql de aprendizaje?

Hay muchas advertencias en las respuestas y comentarios sobre problemas de rendimiento si no eres consistente en las opciones.

Hay comentarios pro / con nvarchar para el rendimiento.

Hay comentarios pro / con varchar para el rendimiento.

Tengo un requisito particular para una tabla con muchos cientos de columnas, ¿lo que en sí mismo es probablemente inusual?

Estoy eligiendo varchar para evitar acercarme al límite de tamaño de registro de la tabla de 8060 bytes del servidor SQL * 2012.

El uso de nvarchar, para mí, supera este límite de 8060 bytes.

También estoy pensando que debo hacer coincidir los tipos de datos de las tablas de códigos relacionadas con los tipos de datos de la tabla central primaria.

He visto el uso de la columna varchar en este lugar de trabajo, el Gobierno de Australia del Sur, por los desarrolladores de bases de datos con experiencia anterior, donde el recuento de filas de la tabla será de varios millones o más (y muy pocas columnas nvarchar, si las hay, en estas tablas muy grandes), por lo que quizás los volúmenes de fila de datos esperados se vuelvan parte de esta decisión.

nvarchar es seguro de usar en comparación con varchar para hacer que nuestro código sea libre de errores (no coincide el tipo) porque nvarchar también permite caracteres Unicode . Cuando usamos la condición where en la consulta de SQL Server y si estamos usando el operador = , se producirá un error algunas veces. La razón probable de esto es que nuestra columna de mapeo se definirá en varchar . Si lo definimos en nvarchar , este problema no ocurrirá. Sin embargo, seguimos con varchar y evitamos este problema, es mejor que utilicemos la palabra clave LIKE en lugar de = .

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow