Hvis du har noget tæt på et valg, skal du bruge et Unicode-tegnsæt til hele databasen. Livet generelt er bare blændende nemmere på den måde.
- Der er masser af tredjepartsværktøjer og biblioteker, der simpelthen ikke understøtter NCHAR/NVARCHAR2-kolonner, eller som ikke gør det behageligt at arbejde med NCHAR/NVARCHAR2-kolonner. Det er f.eks. ekstremt irriterende, når dit skinnende nye rapporteringsværktøj ikke kan rapportere om dine NVARCHAR2-data.
- For brugerdefinerede applikationer kræver arbejdet med NCHAR/NVARCHAR2-kolonner at springe gennem nogle ramme, som arbejde med CHAR/VARCHAR2 Unicode-kodede kolonner ikke gør. I JDBC-kode, for eksempel, ville du konstant kalde Statement.setFormOfUse-metoden. Andre sprog og rammer vil have andre gotchas; nogle vil være relativt veldokumenterede og mindre andre vil være relativt uklare.
- Mange indbyggede pakker vil kun acceptere (eller returnere) en VARCHAR2 i stedet for en NVARCHAR2. Du vil stadig være i stand til at ringe til dem på grund af implicit konvertering, men du kan ende med tegnsætkonverteringsproblemer.
- Generelt gør det at være i stand til at undgå tegnsætkonverteringsproblemer i databasen og at flytte disse problemer til den kant, hvor databasen faktisk sender eller modtager data fra en klient, arbejdet med at udvikle en applikation meget lettere. Det er nok arbejde at fejlsøge tegnsætkonverteringsproblemer, der skyldes netværkstransmission - at finde ud af, at nogle data blev ødelagt, når en lagret procedure sammenkædede data fra en VARCHAR2 og en NVARCHAR2 og gemte resultatet i en VARCHAR2, før de blev sendt over netværket. være ulidelig.
Oracle har designet NCHAR/NVARCHAR2-datatyperne til tilfælde, hvor du forsøger at understøtte ældre applikationer, der ikke understøtter Unicode i den samme database som nye applikationer, der bruger Unicode, og til tilfælde, hvor det er fordelagtigt at gemme nogle Unicode-data med en anden kodning (dvs. du har en stor mængde japanske data, som du foretrækker at gemme ved hjælp af UTF-16-kodningen i en NVARCHAR2 i stedet for UTF-8-kodningen). Hvis du ikke er i en af disse to situationer, og det ikke lyder som om du er det, ville jeg undgå NCHAR/NVARCHAR2 for enhver pris.
Svar på dine opfølgninger
Vores applikation er normalt alene på Oracle-databasen og tager sig selv af dataene. Anden software, der forbinder til databasen, er begrænset til Toad, Tora eller SQL-udvikler.
Hvad mener du med "selv sørger for dataene"? Jeg håber ikke, du siger, at du har konfigureret din applikation til at omgå Oracles tegnsætkonverteringsrutiner, og at du selv udfører al konvertering af tegnsæt.
Jeg antager også, at du bruger en slags API/bibliotek til at få adgang til databasen, selvom det er OCI. Har du undersøgt, hvilke ændringer du skal foretage i din applikation for at understøtte NCHAR/NVARCHAR2, og om den API, du bruger, understøtter NCHAR/NVARCHAR2? Det faktum, at du får Unicode-data i C++, indikerer faktisk ikke, at du ikke behøver at foretage (potentielt signifikante) ændringer for at understøtte NCHAR/NVARCHAR2-kolonner.
Vi bruger også SQL*Loader og SQL*Plus til at kommunikere med databasen til grundlæggende erklæringer eller til at opgradere mellem versioner af produktet. Vi har ikke hørt om noget specifikt problem med al denne software vedrørende NVARCHAR2.
Disse applikationer fungerer alle sammen med NCHAR/NVARCHAR2. NCHAR/NVARCHAR2 introducerer nogle yderligere kompleksiteter i scripts, især hvis du forsøger at kode strengkonstanter, der ikke kan repræsenteres i databasens tegnsæt. Du kan dog helt sikkert løse problemerne.
Vi er heller ikke klar over, at databaseadministratorer blandt vores kunder gerne vil bruge andre værktøjer på databasen, som ikke kunne understøtte data på NVARCHAR2, og vi er ikke rigtig bekymrede for, om deres værktøjer kan forstyrre, når alt kommer til alt, de er dygtige til deres job og kan finde andre værktøjer, hvis det er nødvendigt.
Selvom jeg er sikker på, at dine kunder kan finde alternative måder at arbejde med dine data på, er det meget sandsynligt, at hvis din applikation ikke spiller godt sammen med deres virksomhedsrapporteringsværktøj eller deres enterprise ETL-værktøj eller hvilke desktopværktøjer, de tilfældigvis har erfaring med. at kunden vil give din ansøgning skylden frem for deres værktøjer. Det bliver nok ikke et showstopper, men der er heller ingen fordel i at forvolde kunder unødigt sorg. Det får dem måske ikke til at bruge en konkurrents produkt, men det vil ikke gøre dem ivrige efter at omfavne dit produkt.
Kunne vi også forvente brud på ydeevnen, hvis vores applikation (der er kompileret under Visual C++), der bruger wchar_t til at gemme UTF-16, har for at udføre kodningskonverteringer på alle behandlede data?
Jeg er ikke sikker på, hvilke "konverteringer" du taler om. Dette kan komme tilbage til mit oprindelige spørgsmål om, hvorvidt du siger, at du omgår Oracles NLS-lag for at udføre tegnsætkonvertering på egen hånd.
Min bundlinje er dog, at jeg ikke ser nogen fordele ved at bruge NCHAR/NVARCHAR2 givet det, du beskriver. Der er masser af potentielle ulemper ved at bruge dem. Selvom du kan eliminere 99% af ulemperne som irrelevante for dine særlige behov, står du dog stadig over for en situation, hvor det i bedste fald er en vask mellem de to tilgange. I betragtning af det vil jeg meget hellere gå med den tilgang, der maksimerer fleksibiliteten fremadrettet, og det er at konvertere hele databasen til Unicode (AL32UTF8 formentlig) og bare bruge det.