Als je iets in de buurt hebt van een keuze, gebruik dan een Unicode-tekenset voor de hele database. Het leven in het algemeen is op die manier gewoon verblindend gemakkelijker.
- Er zijn tal van hulpprogramma's en bibliotheken van derden die gewoon geen NCHAR/NVARCHAR2-kolommen ondersteunen of die het werken met NCHAR/NVARCHAR2-kolommen niet prettig maken. Het is bijvoorbeeld buitengewoon vervelend wanneer uw glimmende nieuwe rapportagetool niet kan rapporteren over uw NVARCHAR2-gegevens.
- Voor aangepaste toepassingen vereist het werken met NCHAR/NVARCHAR2-kolommen het springen door een aantal hoepels die werken met CHAR/ VARCHAR2 Unicode-gecodeerde kolommen niet. In JDBC-code zou je bijvoorbeeld constant de methode Statement.setFormOfUse aanroepen. Andere talen en frameworks zullen andere problemen hebben; sommige zullen relatief goed gedocumenteerd zijn en andere zullen relatief obscuur zijn.
- Veel ingebouwde pakketten accepteren (of retourneren) alleen een VARCHAR2 in plaats van een NVARCHAR2. U kunt ze nog steeds bellen vanwege impliciete conversie, maar u kunt problemen krijgen met de conversie van tekensets.
- Over het algemeen maakt het veel gemakkelijker om een applicatie te ontwikkelen als je in staat bent om problemen met de conversie van tekensets in de database te voorkomen en deze problemen naar de rand te delegeren waar de database daadwerkelijk gegevens van een klant verzendt of ontvangt. Het is voldoende werk om de conversieproblemen van tekensets op te sporen die het gevolg zijn van netwerktransmissie -- uitzoeken dat sommige gegevens beschadigd raakten toen een opgeslagen procedure gegevens van een VARCHAR2 en een NVARCHAR2 aaneenvoegde en het resultaat opsloeg in een VARCHAR2 voordat het over het netwerk werd verzonden, kan ondraaglijk zijn.
Oracle heeft de NCHAR/NVARCHAR2-gegevenstypen ontworpen voor gevallen waarin u oudere toepassingen probeert te ondersteunen die Unicode niet ondersteunen in dezelfde database als nieuwe toepassingen die Unicode gebruiken en voor gevallen waarin het voordelig is om sommige Unicode-gegevens op te slaan met een andere codering (d.w.z. u hebt een grote hoeveelheid Japanse gegevens die u liever opslaat met de UTF-16-codering in een NVARCHAR2 in plaats van de UTF-8-codering). Als u zich niet in een van deze twee situaties bevindt, en het klinkt niet alsof u dat wel bent, zou ik NCHAR/NVARCHAR2 ten koste van alles vermijden.
Reageren op uw follow-ups
Onze applicatie staat meestal alleen in de Oracle-database en zorgt zelf voor de gegevens. Andere software die verbinding maakt met de database is beperkt tot Toad-, Tora- of SQL-ontwikkelaars.
Wat bedoel je met "zorgt voor de gegevens zelf"? Ik hoop dat je niet zegt dat je je applicatie hebt geconfigureerd om de tekensetconversieroutines van Oracle te omzeilen en dat je alle tekensetconversies zelf doet.
Ik ga er ook van uit dat je een soort API / bibliotheek gebruikt om toegang te krijgen tot de database, zelfs als dat OCI is. Heeft u gekeken welke wijzigingen u in uw toepassing moet aanbrengen om NCHAR/NVARCHAR2 te ondersteunen en of de API die u gebruikt NCHAR/NVARCHAR2 ondersteunt? Het feit dat u Unicode-gegevens in C++ krijgt, betekent niet dat u geen (mogelijk significante) wijzigingen hoeft aan te brengen om NCHAR/NVARCHAR2-kolommen te ondersteunen.
We gebruiken ook SQL*Loader en SQL*Plus om te communiceren met de database voor basisinstructies of om te upgraden tussen versies van het product. We hebben nog nooit gehoord van een specifiek probleem met al die software met betrekking tot NVARCHAR2.
Die toepassingen werken allemaal met NCHAR/NVARCHAR2. NCHAR/NVARCHAR2 introduceert een aantal extra complexiteiten in scripts, vooral als u tekenreeksconstanten probeert te coderen die niet kunnen worden weergegeven in de databasetekenset. Je kunt de problemen echter zeker omzeilen.
We zijn ons er ook niet van bewust dat databasebeheerders onder onze klanten andere tools op de database zouden willen gebruiken die geen gegevens op NVARCHAR2 konden ondersteunen en we maken ons niet echt zorgen of hun tools zouden kunnen storen, ze zijn tenslotte bekwaam in hun werk en kunnen indien nodig andere tools vinden.
Hoewel ik er zeker van ben dat uw klanten alternatieve manieren kunnen vinden om met uw gegevens te werken, is het zeer waarschijnlijk dat als uw toepassing niet goed samengaat met hun enterprise-rapportagetool of hun enterprise ETL-tool of welke desktoptool ze ook ervaren, dat de klant uw toepassing de schuld zal geven in plaats van hun tools. Het zal waarschijnlijk geen showstopper zijn, maar het heeft ook geen zin om klanten onnodig verdriet te doen. Dat drijft hen misschien niet om het product van een concurrent te gebruiken, maar het zal ze niet enthousiast maken om uw product te omarmen.
Kunnen we ook prestatieverlies verwachten als onze applicatie (die is gecompileerd onder Visual C++), die wchar_t gebruikt om UTF-16 op te slaan, coderingsconversies moet uitvoeren op alle verwerkte gegevens?
Ik weet niet zeker over welke "conversies" je het hebt. Dit kan terugkomen op mijn oorspronkelijke vraag of u stelt dat u de NLS-laag van Oracle omzeilt om zelf tekensetconversie uit te voeren.
Waar het echter op neerkomt, is dat ik geen voordelen zie in het gebruik van NCHAR/NVARCHAR2 gezien wat je beschrijft. Er zijn tal van potentiële nadelen aan het gebruik ervan. Zelfs als je 99% van de nadelen kunt elimineren als irrelevant voor je specifieke behoeften, wordt je nog steeds geconfronteerd met een situatie waarin het op zijn best een was tussen de twee benaderingen is. Gezien dat, zou ik veel liever kiezen voor de aanpak die de flexibiliteit in de toekomst maximaliseert, en dat is de hele database converteren naar Unicode (vermoedelijk AL32UTF8) en dat gewoon gebruiken.