Wenn Sie auch nur annähernd eine Wahl haben, verwenden Sie einen Unicode-Zeichensatz für die gesamte Datenbank. Das Leben im Allgemeinen ist so einfach viel einfacher.
- Es gibt viele Dienstprogramme und Bibliotheken von Drittanbietern, die NCHAR/NVARCHAR2-Spalten einfach nicht unterstützen oder die das Arbeiten mit NCHAR/NVARCHAR2-Spalten nicht angenehm machen. Es ist zum Beispiel extrem ärgerlich, wenn Ihr brandneues Reporting-Tool Ihre NVARCHAR2-Daten nicht melden kann.
- Bei benutzerdefinierten Anwendungen erfordert das Arbeiten mit NCHAR/NVARCHAR2-Spalten ein Durchbrechen einiger Hürden, was bei der Arbeit mit CHAR/VARCHAR2-Unicode-codierten Spalten nicht der Fall ist. In JDBC-Code würden Sie beispielsweise ständig die Methode Statement.setFormOfUse aufrufen. Andere Sprachen und Frameworks haben andere Fallstricke; einige werden relativ gut dokumentiert sein und kleinere andere werden relativ obskur sein.
- Viele eingebaute Pakete akzeptieren (oder geben) nur VARCHAR2 statt NVARCHAR2 zurück. Sie können sie wegen der impliziten Konvertierung immer noch aufrufen, aber es kann zu Problemen bei der Zeichensatzkonvertierung kommen.
- Im Allgemeinen macht die Möglichkeit, Probleme bei der Zeichensatzkonvertierung innerhalb der Datenbank zu vermeiden und diese Probleme an den Rand zu verlagern, wo die Datenbank tatsächlich Daten von einem Client sendet oder empfängt, die Entwicklung einer Anwendung viel einfacher. Es ist genug Arbeit, Probleme bei der Zeichensatzkonvertierung zu debuggen, die sich aus der Netzwerkübertragung ergeben – herauszufinden, dass einige Daten beschädigt wurden, als eine gespeicherte Prozedur Daten aus einem VARCHAR2 und einem NVARCHAR2 verkettete und das Ergebnis in einem VARCHAR2 speicherte, bevor es über das Netzwerk gesendet werden konnte qualvoll sein.
Oracle hat die NCHAR/NVARCHAR2-Datentypen für Fälle entwickelt, in denen Sie versuchen, ältere Anwendungen zu unterstützen, die Unicode nicht in derselben Datenbank wie neue Anwendungen unterstützen, die Unicode verwenden, und für Fälle, in denen es vorteilhaft ist, einige Unicode-Daten mit einer anderen zu speichern Codierung (d. h. Sie haben eine große Menge japanischer Daten, die Sie lieber mit der UTF-16-Codierung in einem NVARCHAR2 als mit der UTF-8-Codierung speichern möchten). Wenn Sie sich nicht in einer dieser beiden Situationen befinden und es sich nicht danach anhört, würde ich NCHAR/NVARCHAR2 um jeden Preis vermeiden.
Antworten auf Ihre Follow-ups
Unsere Anwendung befindet sich in der Regel allein auf der Oracle-Datenbank und kümmert sich selbst um die Daten. Andere Software, die sich mit der Datenbank verbindet, ist auf Toad, Tora oder SQL Developer beschränkt.
Was meinst du mit "kümmert sich selbst um die Daten"? Ich hoffe, Sie sagen nicht, dass Sie Ihre Anwendung so konfiguriert haben, dass sie die Zeichensatzkonvertierungsroutinen von Oracle umgeht, und dass Sie die gesamte Zeichensatzkonvertierung selbst durchführen.
Ich gehe auch davon aus, dass Sie eine Art API/Bibliothek verwenden, um auf die Datenbank zuzugreifen, auch wenn es sich um OCI handelt. Haben Sie sich angesehen, welche Änderungen Sie an Ihrer Anwendung vornehmen müssen, um NCHAR/NVARCHAR2 zu unterstützen, und ob die von Ihnen verwendete API NCHAR/NVARCHAR2 unterstützt? Die Tatsache, dass Sie Unicode-Daten in C++ erhalten, bedeutet nicht wirklich, dass Sie keine (potenziell signifikanten) Änderungen vornehmen müssen, um NCHAR/NVARCHAR2-Spalten zu unterstützen.
Wir verwenden auch SQL*Loader und SQL*Plus, um mit der Datenbank für grundlegende Anweisungen zu kommunizieren oder zwischen Versionen des Produkts zu aktualisieren. Wir haben von keinem spezifischen Problem mit all dieser Software in Bezug auf NVARCHAR2 gehört.
Diese Anwendungen arbeiten alle mit NCHAR/NVARCHAR2. NCHAR/NVARCHAR2 führen einige zusätzliche Komplexitäten in Skripten ein, insbesondere wenn Sie versuchen, Zeichenfolgenkonstanten zu codieren, die im Zeichensatz der Datenbank nicht darstellbar sind. Sie können die Probleme jedoch sicherlich umgehen.
Uns ist auch nicht bewusst, dass Datenbankadministratoren unter unseren Kunden andere Tools auf der Datenbank verwenden möchten, die keine Daten auf NVARCHAR2 unterstützen könnten, und wir sind nicht wirklich besorgt darüber, ob ihre Tools stören könnten, schließlich sind sie in ihrem Job erfahren und können bei Bedarf andere Tools finden.
Ich bin mir zwar sicher, dass Ihre Kunden alternative Möglichkeiten finden werden, mit Ihren Daten zu arbeiten, aber wenn Ihre Anwendung nicht gut mit ihrem Enterprise-Reporting-Tool oder ihrem Enterprise-ETL-Tool oder anderen Desktop-Tools zusammenspielt, mit denen sie Erfahrung haben, ist das sehr wahrscheinlich dass der Kunde Ihrer Anwendung die Schuld gibt und nicht seinen Tools. Es wird wahrscheinlich kein Showstopper sein, aber es bringt auch keinen Vorteil, Kunden unnötig Kummer zu bereiten. Das bringt sie vielleicht nicht dazu, das Produkt eines Mitbewerbers zu verwenden, aber es wird sie nicht dazu bringen, Ihr Produkt anzunehmen.
Können wir auch mit Leistungseinbußen rechnen, wenn unsere Anwendung (die unter Visual C++ kompiliert ist), die wchar_t zum Speichern von UTF-16 verwendet, Codierungskonvertierungen für alle verarbeiteten Daten durchführen muss?
Ich bin mir nicht sicher, von welchen "Conversions" Sie sprechen. Dies könnte auf meine anfängliche Frage zurückkommen, ob Sie angeben, dass Sie die NLS-Schicht von Oracle umgehen, um die Zeichensatzkonvertierung selbst durchzuführen.
Mein Fazit ist jedoch, dass ich angesichts dessen, was Sie beschreiben, keine Vorteile in der Verwendung von NCHAR/NVARCHAR2 sehe. Es gibt viele potenzielle Nachteile bei ihrer Verwendung. Selbst wenn Sie 99 % der Nachteile als irrelevant für Ihre speziellen Bedürfnisse eliminieren können, stehen Sie immer noch vor einer Situation, in der es bestenfalls zu einem Wechsel zwischen den beiden Ansätzen kommt. Angesichts dessen würde ich viel lieber den Ansatz wählen, der die Flexibilität für die Zukunft maximiert, und der darin besteht, die gesamte Datenbank in Unicode (AL32UTF8 vermutlich) zu konvertieren und nur das zu verwenden.
