nls_nchar_characterset - Oracle Text no funcionará con NVARCHAR2. ¿Qué más podría no estar disponible?

oracle utf8 character set

Question

Vamos a migrar una aplicación para que sea compatible con Unicode y tengamos que elegir entre un conjunto de caracteres Unicode para toda la base de datos o columnas Unicode almacenadas en N [VAR] CHAR2.

Sabemos que ya no tendremos la posibilidad de indexar los contenidos de la columna con Oracle Text si elegimos NVARCHAR2, porque Oracle Text solo puede indexar columnas basadas en el tipo CHAR.

Aparte de eso, ¿es probable que surjan otras diferencias importantes cuando se aprovechan las posibilidades de Oracle?

Además, ¿es probable que se agreguen algunas características nuevas en las versiones más nuevas de Oracle, pero que solo admitan columnas CHAR o columnas NCHAR pero no ambas?

Gracias por sus respuestas.

Nota después de la respuesta de Justin:

Gracias por su respuesta. Discutiré sus puntos, aplicados a nuestro caso:

Nuestra aplicación generalmente está sola en la base de datos Oracle y se ocupa de los datos en sí. Otro software que se conecta a la base de datos está limitado a Toad, Tora o SQL developer.

También utilizamos SQL * Loader y SQL * Plus para comunicarnos con la base de datos en busca de declaraciones básicas o para actualizar entre versiones del producto. No hemos oído hablar de ningún problema específico con todos esos software con respecto a NVARCHAR2.

Tampoco somos conscientes de que los administradores de bases de datos entre nuestros clientes desearían utilizar otras herramientas en la base de datos que no pudieran admitir datos en NVARCHAR2 y no estamos realmente preocupados de si sus herramientas pueden interrumpir, después de todo, son expertos en su trabajo y pueden encontrar otras herramientas si es necesario.

Sus dos últimos puntos son más perspicaces para nuestro caso. No usamos muchos paquetes integrados de Oracle, pero aún sucede. Exploraremos ese problema.

¿Podríamos también esperar una ruptura de rendimiento si nuestra aplicación (que está compilada en Visual C ++), que usa wchar_t para almacenar UTF-16, tiene que realizar conversiones de codificación en todos los datos procesados?

Answer 1

Si tiene algo cercano a una elección, use un juego de caracteres Unicode para toda la base de datos. La vida en general es simplemente más deslumbrante de esa manera.

• Hay muchas utilidades y bibliotecas de terceros que simplemente no admiten columnas NCHAR / NVARCHAR2 o que no hacen que trabajar con columnas NCHAR / NVARCHAR2 sea agradable. Es extremadamente molesto, por ejemplo, cuando su nueva herramienta de informes brillante no puede informar sobre sus datos NVARCHAR2.
• Para las aplicaciones personalizadas, trabajar con columnas NCHAR / NVARCHAR2 requiere saltar algunos aros que no funciona con las columnas codificadas Unicode CHAR / VARCHAR2. En el código JDBC, por ejemplo, estarías constantemente llamando al método Statement.setFormOfUse. Otros lenguajes y marcos tendrán otros inconvenientes; algunos estarán relativamente bien documentados y otros menores serán relativamente oscuros.
• Muchos paquetes incorporados solo aceptarán (o devolverán) un VARCHAR2 en lugar de un NVARCHAR2. Todavía podrá llamarlos debido a una conversión implícita, pero puede terminar con problemas de conversión del juego de caracteres.
• En general, poder evitar problemas de conversión de conjunto de caracteres dentro de la base de datos y relegar esos problemas al límite donde la base de datos está realmente enviando o recibiendo datos de un cliente hace que el trabajo de desarrollar una aplicación sea mucho más fácil. Es suficiente trabajo para depurar problemas de conversión de conjuntos de caracteres que resultan de la transmisión de red, descubriendo que algunos datos se corrompieron cuando un procedimiento almacenado concatenó datos de un VARCHAR2 y un NVARCHAR2 y almacenó el resultado en un VARCHAR2 antes de que se enviara a través de la red. ser insoportable

Oracle diseñó los tipos de datos NCHAR / NVARCHAR2 para casos en los que intenta admitir aplicaciones heredadas que no admiten Unicode en la misma base de datos que las nuevas aplicaciones que usan Unicode y para casos donde es beneficioso almacenar algunos datos Unicode con un codificación (es decir, tiene una gran cantidad de datos japoneses que preferiría almacenar utilizando la codificación UTF-16 en una NVARCHAR2 en lugar de la codificación UTF-8). Si no estás en una de esas dos situaciones, y no suena como lo eres, evitaría NCHAR / NVARCHAR2 a toda costa.

Respondiendo a sus seguimientos

Nuestra aplicación generalmente está sola en la base de datos Oracle y se ocupa de los datos en sí. Otro software que se conecta a la base de datos está limitado a Toad, Tora o SQL developer.

¿Qué quieres decir con "se ocupa de los datos en sí"? Espero que no estés diciendo que has configurado tu aplicación para eludir las rutinas de conversión del juego de caracteres de Oracle y que tú mismo realizas la conversión de conjunto de caracteres.

También supongo que está utilizando algún tipo de API / biblioteca para acceder a la base de datos, incluso si es OCI. ¿Ha investigado qué cambios necesitará realizar en su aplicación para admitir NCHAR / NVARCHAR2 y si la API que está utilizando admite NCHAR / NVARCHAR2? El hecho de que esté obteniendo datos Unicode en C ++ en realidad no indica que no necesite realizar cambios (potencialmente significativos) para admitir columnas NCHAR / NVARCHAR2.

También utilizamos SQL * Loader y SQL * Plus para comunicarnos con la base de datos en busca de declaraciones básicas o para actualizar entre versiones del producto. No hemos oído hablar de ningún problema específico con todos esos software con respecto a NVARCHAR2.

Esas aplicaciones todas funcionan con NCHAR / NVARCHAR2. NCHAR / NVARCHAR2 introduce algunas complejidades adicionales en las secuencias de comandos, especialmente si está tratando de codificar las constantes de cadena que no son representables en el conjunto de caracteres de la base de datos. Sin embargo, puedes evitar los problemas.

Tampoco somos conscientes de que los administradores de bases de datos entre nuestros clientes desearían utilizar otras herramientas en la base de datos que no pudieran admitir datos en NVARCHAR2 y no estamos realmente preocupados de si sus herramientas pueden interrumpir, después de todo, son expertos en su trabajo y pueden encontrar otras herramientas si es necesario.

Aunque estoy seguro de que sus clientes pueden encontrar formas alternativas de trabajar con sus datos, si su aplicación no funciona bien con su herramienta de informes empresariales o su herramienta ETL empresarial o las herramientas de escritorio con las que tienen experiencia, es muy probable que que el cliente culpe a su aplicación en lugar de a sus herramientas. Probablemente no sea un impedimento para el espectáculo, pero tampoco beneficia a los clientes la aflicción innecesaria. Eso puede no llevarlos a usar el producto de un competidor, pero no los entusiasmará adoptar su producto.

¿Podríamos también esperar una ruptura de rendimiento si nuestra aplicación (que está compilada en Visual C ++), que usa wchar_t para almacenar UTF-16, tiene que realizar conversiones de codificación en todos los datos procesados?

No estoy seguro de qué "conversiones" estás hablando. Esto puede volver a mi pregunta inicial sobre si está indicando que está pasando por alto la capa NLS de Oracle para hacer la conversión del juego de caracteres por su cuenta.

Mi conclusión, sin embargo, es que no veo ninguna ventaja al usar NCHAR / NVARCHAR2 dado lo que describes. Existen muchas desventajas potenciales para su uso. Incluso si puede eliminar el 99% de las desventajas como irrelevantes para sus necesidades particulares, sin embargo, todavía se enfrenta a una situación en la que, en el mejor de los casos, es un lavado entre los dos enfoques. Dado que prefiero seguir con el enfoque que maximiza la flexibilidad en el futuro, y eso es convertir la base de datos entera a Unicode (presumiblemente AL32UTF8) y simplemente usar eso.