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

¿Es solo que nvarcharadmite caracteres multibyte? Si ese es el caso, ¿hay realmente algún punto, aparte de las preocupaciones de almacenamiento, para usar varchars?

Una nvarcharcolumna puede almacenar cualquier dato Unicode. Una varcharcolumna está restringida a una página de códigos de 8 bits. Algunas personas piensan que varchardebería usarse porque ocupa menos espacio. Creo que esta no es la respuesta correcta. Las incompatibilidades de la página de códigos son un problema, y ​​Unicode es la cura para los problemas de la página de códigos. Con un disco y una memoria baratos hoy en día, ya no hay razón para perder el tiempo revisando páginas de códigos.

Todos los sistemas operativos y plataformas de desarrollo modernos utilizan Unicode internamente. Al usar en nvarcharlugar de varchar, puede evitar hacer conversiones de codificación cada vez que lee o escribe 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 usa solo ASCII, todavía recomendaría usar Unicode en la base de datos. El sistema operativo y los algoritmos de recopilación de bases de datos 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.

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

nvarchar : datos de caracteres Unicode de longitud variable. Depende de la recopilación de la base de datos para las comparaciones.

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

Siempre uso nvarchar, ya que permite que todo lo que estoy construyendo resista casi cualquier dato que le arroje. Mi sistema CMS hace chino por accidente, porque usé nvarchar. En estos días, las nuevas aplicaciones no deberían preocuparse realmente 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. Es posible que pueda 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 bastante idénticos. Deja de leer ahora, solo adelante. De lo contrario, o si no tiene control sobre el conjunto de caracteres de Oracle, siga leyendo.

VARCHAR: los datos se almacenan en la codificación NLS_CHARACTERSET. Si hay otras instancias de la base de datos en el mismo servidor, puede estar restringido por ellas; y viceversa, ya que debes compartir la configuración. Tal campo puede almacenar cualquier información que pueda codificarse usando ese juego 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 acentuadas y algunos otros (como € y -). Su aplicación sería útil solo para algunos entornos locales, ya que no puede operar en ningún otro lugar del mundo. Por esta razón, se considera una mala idea.

NVARCHAR: 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 se diseñó a medida para un entorno local específico. Los campos NVARCHAR se almacenan en codificación UTF-8 o UTF-16, basándose en la configuración de NLS, irónicamente. UTF-8 es muy eficiente para los idiomas "occidentales", mientras que todavía admite idiomas asiáticos. UTF-16 es muy eficiente para los idiomas asiáticos, al tiempo que admite idiomas "occidentales". Si le preocupa el espacio de almacenamiento, elija una configuración de NLS para 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 usan 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. Usar NVARCHAR evita la conversión.

En pocas palabras: ¡use NVARCHAR! Evita limitaciones y dependencias, está bien para el espacio de almacenamiento y generalmente también es mejor 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

1. Los índices pueden fallar cuando no se usan los tipos de datos correctos:
   En SQL Server: cuando tiene un índice sobre una columna VARCHAR y le presenta una Cadena Unicode, SQL Server 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 Server no puede usar el índice. Al revés, no tiene este problema (cuando proporciona SmallInt o Ansi-Code a una columna indexada BigInt ot NVARCHAR).

2. 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. Si bien SQL Server tiene VARCHAR y NVARCHAR, una base de datos Apache / Derby solo tiene VARCHAR y 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 codificar caracteres de muchos otros idiomas como árabe, hebreo, chino y japonés en un solo conjunto de caracteres.

Eso significa que los Unicodes están usando 2 bytes por carácter para almacenar y los no Unicodes usan solo un byte por carácter para almacenar. Lo que significa que los Unicodes necesitan una capacidad doble para almacenar en comparación con los no Unicodes.

Tienes razón. nvarcharalmacena datos Unicode mientras varcharalmacena datos de caracteres de un solo byte. Aparte de las diferencias de almacenamiento ( nvarcharrequiere el doble de espacio de almacenamiento varchar), que ya se ha mencionado, la principal razón para preferir nvarcharmás varcharsería internacionalización (es decir, cadenas de almacenamiento en otros idiomas).

Yo diría que depende.

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

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

Aunque NVARCHARalmacena Unicode, debe considerar, con la ayuda de la recopilación, que también puede usar VARCHARy guardar sus datos de sus idiomas locales.

Solo imagine el siguiente escenario.

La clasificación de su base de datos es persa y guarda un valor como 'علی' (escritura persa de Ali) en el VARCHAR(10)tipo de datos. 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 clasificació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á usando una gran base de datos que es para el uso de su idioma local, 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.

Eché un vistazo a las respuestas y muchos parecen recomendar usarlo nvarcharmás varchar, porque el espacio ya no es un problema, por lo que no hay ningún daño en habilitar Unicode para un poco de almacenamiento adicional. 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. Entonces, si tiene un varchar(900), aún 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 le recomiendo usarlo.

En general, en las bases de datos, recomiendo ajustarse al tamaño que necesita, porque siempre puede expandirse. Por ejemplo, un colega en el trabajo alguna vez pensó que no hay daño en el uso nvarchar(max)de 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 lo rechazó. Sin embargo, si comenzó con incluso varchar(5), podríamos simplemente haberlo ampliado más tarde a lo que necesitamos sin un problema que nos obligue a hacer un plan de migración de campo para solucionar este problema.

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

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

1252, que es el Latin1 (ANSI), es el más común. Los juegos 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.

Estándar Unicode

Cuando los sistemas que usan múltiples páginas de códigos se usan en una red, se hace difícil administrar la comunicación. Para estandarizar las cosas, el consorcio ISO y Unicode introdujo el Unicode . Unicode usa 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, cada símbolo se representará 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 text)
• Unicode (nchar, nvarchar y ntext)

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

Tengo que decir aquí (¡me doy cuenta de que probablemente voy a abrirme a una paliza!), Pero seguramente la única vez en que NVARCHARes realmente más útil (¡noten más allí!) Que VARCHARcuando todas las colaciones en general de los sistemas dependientes y dentro de la base de datos son los mismos ...? Si no, entonces la conversión de colación tiene que suceder de todos modos, por lo que VARCHARes 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 algo como un campo TEXTo NTEXT, entonces VARCHARproporciona el espacio completo de 8k mientras que NVARCHARsolo proporciona 4k (el doble de bytes, el doble de espacio).

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

• Proyecto o contexto
• Infraestructura
• Sistema de bases de datos

Siga la diferencia entre el servidor SQL VARCHAR y el tipo de datos NVARCHAR . Aquí puedes ver de una manera muy descriptiva.

En general, 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.

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

VarcharEl tamaño de los datos (longitud variable, caracteres no Unicode) es de hasta 8000. 1. Es un tipo de datos de longitud variable

2. Se usa para almacenar caracteres no Unicode

3. 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.

3. Los datos se almacenan en una codificación Unicode. Todos los idiomas son compatibles. (por ejemplo, los idiomas árabe, alemán, hindi, etc., etc.)

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

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

¿Cuáles son las principales diferencias de rendimiento entre los tipos de datos varchar y nvarchar SQL Server?

https://www.sqlservercentral.com/articles/disk-is-cheap-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 es consistente en las elecciones.

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.

Elijo 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 debería 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 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 estos muy grandes tablas), por lo que quizás los volúmenes de fila de datos esperados se vuelvan parte de esta decisión.

nvarchares seguro de usar en comparación con el varcharfin de hacer que nuestro código esté libre de errores (no coinciden los tipos) porque también nvarcharpermite caracteres unicode. Cuando usamos wherecondición en la consulta de SQL Server y si estamos usando el =operador, arrojará errores algunas veces. La razón probable de esto es que nuestra columna de mapeo será diferenciada varchar. Si lo definimos en nvarchareste problema, no sucederá. Aún así nos atenemos varchary evitamos este problema, mejor usamos LIKEpalabras clave en lugar de =.