Si tiene algo parecido a una opción, use un conjunto de caracteres Unicode para toda la base de datos. La vida en general es deslumbrantemente más fácil 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 y brillante herramienta de informes no puede informar sobre sus datos NVARCHAR2.
- Para aplicaciones personalizadas, trabajar con columnas NCHAR/ NVARCHAR2 requiere pasar por algunos obstáculos que no se requieren al trabajar con columnas codificadas CHAR/ VARCHAR2 Unicode. En el código JDBC, por ejemplo, estaría llamando constantemente al método Statement.setFormOfUse. Otros lenguajes y marcos tendrán otras trampas; algunos estarán relativamente bien documentados y otros menores serán relativamente oscuros.
- Muchos paquetes integrados solo aceptarán (o devolverán) un VARCHAR2 en lugar de un NVARCHAR2. Aún podrá llamarlos debido a la conversión implícita, pero puede terminar con problemas de conversión del juego de caracteres.
- En general, ser capaz de evitar problemas de conversión de juegos de caracteres dentro de la base de datos y relegar esos problemas al borde donde la base de datos realmente envía o recibe datos de un cliente hace que el trabajo de desarrollo de una aplicación sea mucho más fácil. Es suficiente trabajo para depurar los problemas de conversión de juegos de caracteres que resultan de la transmisión de la red:descubrir 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 los casos en los que intenta admitir aplicaciones heredadas que no admiten Unicode en la misma base de datos que las aplicaciones nuevas que utilizan Unicode y para los casos en los que es beneficioso almacenar algunos datos Unicode con un formato diferente. codificación (es decir, tiene una gran cantidad de datos japoneses que preferiría almacenar utilizando la codificación UTF-16 en un NVARCHAR2 en lugar de la codificación UTF-8). Si no se encuentra en una de esas dos situaciones, y no parece que lo esté, evitaría NCHAR/NVARCHAR2 a toda costa.
Respondiendo a tus seguimientos
Nuestra aplicación suele estar sola en la base de datos Oracle y se encarga de los datos por sí misma. Otros software que se conectan a la base de datos se limitan a Toad, Tora o SQL Developer.
¿Qué quiere decir con "se ocupa de los datos en sí"? Espero que no esté diciendo que configuró su aplicación para omitir las rutinas de conversión de conjuntos de caracteres de Oracle y que usted mismo realiza todas las conversiones de conjuntos de caracteres.
También asumo 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 es compatible con NCHAR/ NVARCHAR2? El hecho de que obtenga datos Unicode en C++ en realidad no indica que no necesitará realizar cambios (potencialmente significativos) para admitir las columnas NCHAR/ NVARCHAR2.
También usamos SQL*Loader y SQL*Plus para comunicarnos con la base de datos para declaraciones básicas o para actualizar entre versiones del producto. No hemos oído hablar de ningún problema específico con todo el software relacionado con NVARCHAR2.
Todas esas aplicaciones funcionan con NCHAR/ NVARCHAR2. NCHAR/ NVARCHAR2 introduce algunas complejidades adicionales en los scripts, especialmente si intenta codificar constantes de cadena que no se pueden representar en el conjunto de caracteres de la base de datos. Sin embargo, ciertamente puede solucionar los problemas.
Tampoco somos conscientes de que los administradores de bases de datos entre nuestros clientes deseen utilizar otras herramientas en la base de datos que no admitan datos en NVARCHAR2 y no nos preocupa realmente si sus herramientas pueden interrumpir, después de todo, son expertos en su trabajo y pueden encontrar otras herramientas si es necesario.
Si bien 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 cualquier herramienta de escritorio con la que tengan experiencia, es muy probable que que el cliente culpará a su aplicación en lugar de a sus herramientas. Probablemente no será un problema, pero tampoco hay ningún beneficio en causar dolor a los clientes innecesariamente. Es posible que eso no los impulse a usar el producto de un competidor, pero no hará que estén ansiosos por adoptar su producto.
¿Podríamos esperar también una interrupción del rendimiento si nuestra aplicación (compilada con 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á afirmando que está pasando por alto la capa NLS de Oracle para realizar la conversión del conjunto de caracteres por su cuenta.
Sin embargo, mi conclusión es que no veo ninguna ventaja en usar NCHAR/ NVARCHAR2 dado lo que estás describiendo. Hay muchas desventajas potenciales al usarlos. Incluso si puede eliminar el 99% de las desventajas como irrelevantes para sus necesidades particulares, aún se enfrenta a una situación en la que, en el mejor de los casos, es un lavado entre los dos enfoques. Dado eso, prefiero ir con el enfoque que maximiza la flexibilidad en el futuro, y eso es convertir toda la base de datos a Unicode (presumiblemente AL32UTF8) y simplemente usar eso.
