Se você tiver algo próximo a uma escolha, use um conjunto de caracteres Unicode para todo o banco de dados. A vida em geral é incrivelmente mais fácil assim.
- Existem muitos utilitários e bibliotecas de terceiros que simplesmente não suportam colunas NCHAR/ NVARCHAR2 ou que não tornam o trabalho com colunas NCHAR/ NVARCHAR2 agradável. É extremamente irritante, por exemplo, quando sua nova e brilhante ferramenta de relatórios não pode relatar seus dados NVARCHAR2.
- Para aplicativos personalizados, trabalhar com colunas NCHAR/ NVARCHAR2 requer pular alguns aros que trabalhar com colunas codificadas CHAR/ VARCHAR2 Unicode não. No código JDBC, por exemplo, você chamaria constantemente o método Statement.setFormOfUse. Outras linguagens e frameworks terão outras pegadinhas; alguns serão relativamente bem documentados e outros menores serão relativamente obscuros.
- Muitos pacotes integrados só aceitam (ou retornam) um VARCHAR2 em vez de um NVARCHAR2. Você ainda poderá chamá-los devido à conversão implícita, mas pode acabar com problemas de conversão de conjunto de caracteres.
- Em geral, ser capaz de evitar problemas de conversão de conjuntos de caracteres dentro do banco de dados e relegá-los para a borda onde o banco de dados está realmente enviando ou recebendo dados de um cliente torna o trabalho de desenvolvimento de um aplicativo muito mais fácil. É trabalho suficiente para depurar os problemas de conversão do conjunto de caracteres que resultam da transmissão da rede - descobrir que alguns dados foram corrompidos quando um procedimento armazenado concatenou dados de um VARCHAR2 e um NVARCHAR2 e armazenou o resultado em um VARCHAR2 antes de ser enviado pela rede pode ser excruciante.
A Oracle projetou os tipos de dados NCHAR/NVARCHAR2 para casos em que você está tentando oferecer suporte a aplicativos legados que não suportam Unicode no mesmo banco de dados que novos aplicativos que estão usando Unicode e para casos em que é benéfico armazenar alguns dados Unicode com um codificação (ou seja, você tem uma grande quantidade de dados japoneses que prefere armazenar usando a codificação UTF-16 em um NVARCHAR2 em vez da codificação UTF-8). Se você não está em uma dessas duas situações, e não parece que você está, eu evitaria NCHAR/ NVARCHAR2 a todo custo.
Respondendo aos seus acompanhamentos
Nosso aplicativo geralmente fica sozinho no banco de dados Oracle e cuida dos dados por conta própria. Outros softwares que se conectam ao banco de dados são limitados ao Toad, Tora ou SQL developer.
O que você quer dizer com "cuida dos dados em si"? Espero que você não esteja dizendo que configurou seu aplicativo para ignorar as rotinas de conversão do conjunto de caracteres do Oracle e que você mesmo faz toda a conversão do conjunto de caracteres.
Também estou assumindo que você está usando algum tipo de API/biblioteca para acessar o banco de dados, mesmo que seja OCI. Você verificou quais alterações você precisará fazer em seu aplicativo para oferecer suporte a NCHAR/ NVARCHAR2 e se a API que você está usando suporta NCHAR/ NVARCHAR2? O fato de você estar obtendo dados Unicode em C++ não indica que você não precisará fazer alterações (potencialmente significativas) para dar suporte a colunas NCHAR/NVARCHAR2.
Também usamos SQL*Loader e SQL*Plus para comunicar com o banco de dados para instruções básicas ou para atualizar entre as versões do produto. Não temos notícias de nenhum problema específico com todos esses softwares em relação ao NVARCHAR2.
Todos esses aplicativos funcionam com NCHAR/ NVARCHAR2. NCHAR/ NVARCHAR2 introduz algumas complexidades adicionais nos scripts, especialmente se você estiver tentando codificar constantes de cadeia de caracteres que não são representáveis no conjunto de caracteres do banco de dados. Você certamente pode contornar os problemas, no entanto.
Também não estamos cientes de que administradores de banco de dados entre nossos clientes gostariam de usar outras ferramentas no banco de dados que não suportam dados em NVARCHAR2 e não estamos realmente preocupados se suas ferramentas podem interromper, afinal eles são habilidosos em seu trabalho e podem encontrar outras ferramentas se necessário.
Embora eu tenha certeza de que seus clientes podem encontrar maneiras alternativas de trabalhar com seus dados, se seu aplicativo não funcionar bem com a ferramenta de relatórios corporativos ou a ferramenta ETL corporativa ou qualquer ferramenta de desktop com a qual eles tenham experiência, é muito provável que que o cliente irá culpar seu aplicativo em vez de suas ferramentas. Provavelmente não será uma rolha de show, mas também não há benefício em causar sofrimento aos clientes desnecessariamente. Isso pode não levá-los a usar o produto de um concorrente, mas não os deixará ansiosos para adotar seu produto.
Poderíamos também esperar uma quebra de desempenho se nosso aplicativo (que é compilado no Visual C++), que usa wchar_t para armazenar UTF-16, tem que realizar conversões de codificação em todos os dados processados?
Não tenho certeza de que "conversões" você está falando. Isso pode voltar à minha pergunta inicial sobre se você está afirmando que está ignorando a camada NLS da Oracle para fazer a conversão do conjunto de caracteres por conta própria.
Minha conclusão, porém, é que não vejo nenhuma vantagem em usar NCHAR/ NVARCHAR2, dado o que você está descrevendo. Existem muitas desvantagens potenciais em usá-los. Mesmo que você possa eliminar 99% das desvantagens como irrelevantes para suas necessidades específicas, no entanto, ainda está enfrentando uma situação em que, na melhor das hipóteses, é uma lavagem entre as duas abordagens. Dado isso, eu prefiro seguir a abordagem que maximiza a flexibilidade daqui para frente, e isso é converter todo o banco de dados para Unicode (AL32UTF8 presumivelmente) e apenas usá-lo.
