Om du har något i närheten av ett val, använd en Unicode-teckenuppsättning för hela databasen. Livet i allmänhet är bara bländande lättare på det sättet.
- Det finns massor av tredjepartsverktyg och bibliotek som helt enkelt inte stöder NCHAR/NVARCHAR2-kolumner eller som inte gör det trevligt att arbeta med NCHAR/NVARCHAR2-kolumner. Det är till exempel extremt irriterande när ditt glänsande nya rapportverktyg inte kan rapportera om dina NVARCHAR2-data.
- För anpassade applikationer kräver arbete med NCHAR/NVARCHAR2-kolumner att man hoppar genom vissa ramar som man inte gör med CHAR/VARCHAR2 Unicode-kodade kolumner. I JDBC-kod, till exempel, skulle du ständigt anropa metoden Statement.setFormOfUse. Andra språk och ramverk kommer att ha andra gotchas; vissa kommer att vara relativt väldokumenterade och mindre andra kommer att vara relativt oklara.
- Många inbyggda paket accepterar (eller returnerar) bara en VARCHAR2 istället för en NVARCHAR2. Du kommer fortfarande att kunna ringa dem på grund av implicit konvertering, men du kan få problem med teckenuppsättningskonvertering.
- I allmänhet, att kunna undvika teckenuppsättningskonverteringsproblem inom databasen och att förpassa dessa problem till den kant där databasen faktiskt skickar eller tar emot data från en klient gör jobbet med att utveckla en applikation mycket enklare. Det är tillräckligt med arbete att felsöka teckenuppsättningskonverteringsproblem som är ett resultat av nätverksöverföring - att ta reda på att vissa data blev korrupta när en lagrad procedur sammanfogade data från en VARCHAR2 och en NVARCHAR2 och lagrade resultatet i en VARCHAR2 innan den skickades över nätverket. vara olidlig.
Oracle designade NCHAR/NVARCHAR2-datatyperna för fall där du försöker stödja äldre applikationer som inte stöder Unicode i samma databas som nya applikationer som använder Unicode och för fall där det är fördelaktigt att lagra vissa Unicode-data med en annan kodning (dvs. du har en stor mängd japansk data som du föredrar att lagra med UTF-16-kodning i en NVARCHAR2 snarare än UTF-8-kodning). Om du inte är i någon av dessa två situationer, och det inte låter som du är, skulle jag undvika NCHAR/NVARCHAR2 till varje pris.
Svara på dina uppföljningar
Vår applikation är vanligtvis ensam på Oracle-databasen och tar hand om data själv. Annan programvara som ansluter till databasen är begränsad till Toad, Tora eller SQL-utvecklare.
Vad menar du med att "ta hand om datan själv"? Jag hoppas att du inte säger att du har konfigurerat din applikation för att kringgå Oracles rutiner för teckenuppsättningskonvertering och att du gör all teckenuppsättningskonvertering själv.
Jag antar också att du använder någon form av API/bibliotek för att komma åt databasen även om det är OCI. Har du undersökt vilka ändringar du behöver göra i din applikation för att stödja NCHAR/NVARCHAR2 och om API:et du använder stöder NCHAR/NVARCHAR2? Det faktum att du får Unicode-data i C++ indikerar faktiskt inte att du inte behöver göra (potentiellt betydande) ändringar för att stödja NCHAR/NVARCHAR2-kolumner.
Vi använder också SQL*Loader och SQL*Plus för att kommunicera med databasen för grundläggande uttalanden eller för att uppgradera mellan versioner av produkten. Vi har inte hört talas om något specifikt problem med all denna programvara angående NVARCHAR2.
Dessa applikationer fungerar alla med NCHAR/NVARCHAR2. NCHAR/NVARCHAR2 introducerar ytterligare komplexitet i skript, särskilt om du försöker koda strängkonstanter som inte kan representeras i databasens teckenuppsättning. Men du kan säkert lösa problemen.
Vi är inte heller medvetna om att databasadministratörer bland våra kunder skulle vilja använda andra verktyg i databasen som inte kunde stödja data på NVARCHAR2 och vi är inte riktigt oroliga för om deras verktyg kan störa, trots allt är de skickliga i sitt jobb och kan hitta andra verktyg om det behövs.
Även om jag är säker på att dina kunder kan hitta alternativa sätt att arbeta med din data, om din applikation inte fungerar bra med deras företagsrapporteringsverktyg eller deras ETL-verktyg för företag eller vilka skrivbordsverktyg de råkar ha erfarenhet av, är det mycket troligt att kunden kommer att skylla på din applikation snarare än sina verktyg. Det blir nog ingen showstopp, men det är heller ingen fördel med att orsaka kunder sorg i onödan. Det kanske inte får dem att använda en konkurrents produkt, men det gör dem inte ivriga att omfamna din produkt.
Kan vi också förvänta oss prestandaavbrott om vår applikation (som är kompilerad under Visual C++), som använder wchar_t för att lagra UTF-16, har för att utföra kodningskonverteringar på all bearbetad data?
Jag är inte säker på vilka "konverteringar" du pratar om. Detta kan komma tillbaka till min första fråga om huruvida du säger att du kringgår Oracles NLS-lager för att göra teckenuppsättningskonvertering på egen hand.
Min slutsats är dock att jag inte ser några fördelar med att använda NCHAR/NVARCHAR2 med tanke på vad du beskriver. Det finns många potentiella nackdelar med att använda dem. Även om du kan eliminera 99 % av nackdelarna som irrelevanta för dina specifika behov, står du fortfarande inför en situation där det i bästa fall är en tvättning mellan de två tillvägagångssätten. Med tanke på det skulle jag mycket hellre gå med det tillvägagångssätt som maximerar flexibiliteten framöver, och det är att konvertera hela databasen till Unicode (förmodligen AL32UTF8) och bara använda det.