Se hai qualcosa vicino a una scelta, usa un set di caratteri Unicode per l'intero database. La vita in generale è semplicemente incredibilmente più facile in questo modo.
- Ci sono molte utilità e librerie di terze parti che semplicemente non supportano le colonne NCHAR/NVARCHAR2 o che non rendono piacevole il lavoro con le colonne NCHAR/NVARCHAR2. È estremamente fastidioso, ad esempio, quando il tuo nuovo e brillante strumento di creazione di rapporti non può generare rapporti sui tuoi dati NVARCHAR2.
- Per le applicazioni personalizzate, lavorare con le colonne NCHAR/NVARCHAR2 richiede di saltare attraverso alcuni cerchi che non funzionano con le colonne codificate Unicode CHAR/VARCHAR2. Nel codice JDBC, ad esempio, chiamerai costantemente il metodo Statement.setFormOfUse. Altri linguaggi e framework avranno altri trucchi; alcuni saranno relativamente ben documentati e altri minori saranno relativamente oscuri.
- Molti pacchetti integrati accetteranno (o restituiranno) solo un VARCHAR2 anziché un NVARCHAR2. Potrai ancora chiamarli a causa della conversione implicita, ma potresti ritrovarti con problemi di conversione del set di caratteri.
- In generale, essere in grado di evitare problemi di conversione del set di caratteri all'interno del database e relegare tali problemi al limite in cui il database sta effettivamente inviando o ricevendo dati da un client rende il lavoro di sviluppo di un'applicazione molto più semplice. È abbastanza lavoro per eseguire il debug dei problemi di conversione del set di caratteri risultanti dalla trasmissione di rete:capire che alcuni dati sono stati danneggiati quando una procedura memorizzata ha concatenato i dati da un VARCHAR2 e un NVARCHAR2 e ha archiviato il risultato in un VARCHAR2 prima che fosse inviato sulla rete può essere straziante.
Oracle ha progettato i tipi di dati NCHAR/ NVARCHAR2 per i casi in cui si tenta di supportare applicazioni legacy che non supportano Unicode nello stesso database delle nuove applicazioni che utilizzano Unicode e per i casi in cui è vantaggioso archiviare alcuni dati Unicode con un diverso codifica (cioè hai una grande quantità di dati giapponesi che preferiresti archiviare utilizzando la codifica UTF-16 in un NVARCHAR2 anziché la codifica UTF-8). Se non ti trovi in una di queste due situazioni, e sembra che tu non lo sia, eviterei NCHAR/ NVARCHAR2 a tutti i costi.
Rispondendo ai tuoi follow-up
La nostra applicazione è solitamente da sola sul database Oracle e si occupa dei dati stessi. Altri software che si connettono al database sono limitati a Toad, Tora o sviluppatore SQL.
Cosa intendi con "si prende cura dei dati stessi"? Spero che tu non stia dicendo che hai configurato la tua applicazione in modo da ignorare le routine di conversione del set di caratteri di Oracle e che esegui tu stesso la conversione del set di caratteri.
Suppongo anche che tu stia utilizzando una sorta di API/libreria per accedere al database anche se si tratta di OCI. Hai esaminato quali modifiche dovrai apportare alla tua applicazione per supportare NCHAR/ NVARCHAR2 e se l'API che stai utilizzando supporta NCHAR/ NVARCHAR2? Il fatto che stai ricevendo dati Unicode in C++ non indica in realtà che non dovrai apportare modifiche (potenzialmente significative) per supportare le colonne NCHAR/NVARCHAR2.
Utilizziamo anche SQL*Loader e SQL*Plus per comunicare con il database per le istruzioni di base o per eseguire l'aggiornamento tra le versioni del prodotto. Non abbiamo sentito alcun problema specifico con tutti quei software relativi a NVARCHAR2.
Queste applicazioni funzionano tutte con NCHAR/NVARCHAR2. NCHAR/ NVARCHAR2 introducono alcune complessità aggiuntive negli script, in particolare se si tenta di codificare costanti di stringa che non sono rappresentabili nel set di caratteri del database. Tuttavia, puoi sicuramente aggirare i problemi.
Inoltre, non siamo consapevoli del fatto che gli amministratori di database tra i nostri clienti vorrebbero utilizzare altri strumenti sul database che non supportano i dati su NVARCHAR2 e non siamo davvero preoccupati se i loro strumenti potrebbero interrompersi, dopotutto sono esperti nel loro lavoro e potrebbero trovare altri strumenti se necessario.
Anche se sono sicuro che i tuoi clienti possano trovare modi alternativi di lavorare con i tuoi dati, se la tua applicazione non funziona bene con il loro strumento di reporting aziendale o con il loro strumento ETL aziendale o con qualsiasi strumento desktop con cui hanno esperienza, è molto probabile che il cliente incolperà la tua applicazione piuttosto che i suoi strumenti. Probabilmente non sarà un ostacolo allo spettacolo, ma non c'è alcun vantaggio nel causare inutilmente dolore ai clienti. Ciò potrebbe non spingerli a utilizzare il prodotto di un concorrente, ma non li renderà desiderosi di abbracciare il tuo prodotto.
Possiamo anche aspettarci un'interruzione delle prestazioni se la nostra applicazione (che è compilata in Visual C++), che utilizza wchar_t per archiviare UTF-16, deve eseguire conversioni di codifica su tutti i dati elaborati?
Non sono sicuro di quali "conversioni" stai parlando. Questo potrebbe tornare alla mia domanda iniziale sul fatto che stai affermando che stai bypassando il livello NLS di Oracle per eseguire la conversione del set di caratteri da solo.
La mia conclusione, tuttavia, è che non vedo alcun vantaggio nell'usare NCHAR/ NVARCHAR2 dato quello che stai descrivendo. Ci sono molti potenziali svantaggi nell'usarli. Anche se puoi eliminare il 99% degli aspetti negativi in quanto irrilevanti per le tue esigenze particolari, tuttavia, stai comunque affrontando una situazione in cui nella migliore delle ipotesi è un lavaggio tra i due approcci. Detto questo, preferirei di gran lunga adottare l'approccio che massimizza la flessibilità in futuro, ovvero convertire l'intero database in Unicode (presumibilmente AL32UTF8) e utilizzarlo semplicemente.
