選択肢に近いものがある場合は、データベース全体にUnicode文字セットを使用してください。一般的に、生活はそのように盲目的に簡単です。
- NCHAR / NVARCHAR2列をサポートしていない、またはNCHAR/NVARCHAR2列の操作を快適にしないサードパーティのユーティリティやライブラリはたくさんあります。たとえば、光沢のある新しいレポートツールがNVARCHAR2データについてレポートできない場合、これは非常に煩わしいことです。
- カスタムアプリケーションの場合、NCHAR / NVARCHAR2列を操作するには、CHAR /VARCHAR2Unicodeエンコード列を操作しないいくつかのフープをジャンプする必要があります。たとえば、JDBCコードでは、Statement.setFormOfUseメソッドを常に呼び出しています。他の言語とフレームワークには他の落とし穴があります。いくつかは比較的よく文書化され、マイナーなものは比較的あいまいになります。
- 多くの組み込みパッケージは、NVARCHAR2ではなくVARCHAR2のみを受け入れる（または返す）でしょう。暗黙的な変換のためにそれらを呼び出すことはできますが、文字セット変換の問題が発生する可能性があります。
- 一般に、データベース内の文字セット変換の問題を回避し、データベースが実際にクライアントからデータを送受信しているエッジにそれらの問題を委ねることができると、アプリケーションの開発作業がはるかに簡単になります。ネットワーク送信に起因する文字セット変換の問題をデバッグするのに十分な作業です。ストアドプロシージャがVARCHAR2とNVARCHAR2からのデータを連結し、その結果をネットワーク経由で送信する前にVARCHAR2に格納すると、一部のデータが破損することがわかります。耐え難いこと。
Oracleは、Unicodeを使用する新しいアプリケーションと同じデータベースでUnicodeをサポートしないレガシーアプリケーションをサポートしようとしている場合、および一部のUnicodeデータを別のUnicodeデータで格納することが有益な場合のために、NCHAR/NVARCHAR2データタイプを設計しました。エンコーディング（つまり、UTF-8エンコーディングではなくNVARCHAR2でUTF-16エンコーディングを使用して保存したい大量の日本のデータがあります）。これらの2つの状況のいずれにも該当せず、そうでないように思われる場合は、NCHAR/NVARCHAR2を絶対に避けます。
フォローアップへの対応
私たちのアプリケーションは通常、Oracleデータベース上に単独で存在し、データ自体を処理します。データベースに接続するその他のソフトウェアは、Toad、Tora、またはSQL開発者に限定されています。
「データ自体を処理する」とはどういう意味ですか？Oracleの文字セット変換ルーチンをバイパスするようにアプリケーションを構成し、すべての文字セット変換を自分で行うと言っているのではないことを願っています。
また、OCIであっても、データベースにアクセスするために何らかのAPI/ライブラリを使用していることを前提としています。NCHAR / NVARCHAR2をサポートするためにアプリケーションにどのような変更を加える必要があるか、および使用しているAPIがNCHAR / NVARCHAR2をサポートしているかどうかを調べましたか？C ++でUnicodeデータを取得しているという事実は、NCHAR / NVARCHAR2列をサポートするために（潜在的に重要な）変更を加える必要がないことを実際に示しているわけではありません。
また、SQL*LoaderおよびSQL*Plusを使用して、基本的なステートメントのためにデータベースと通信したり、製品のバージョン間でアップグレードしたりします。NVARCHAR2に関して、これらすべてのソフトウェアに特定の問題があることは聞いたことがありません。
これらのアプリケーションはすべてNCHAR/NVARCHAR2で動作します。NCHAR / NVARCHAR2は、特にデータベースの文字セットで表現できない文字列定数をエンコードしようとしている場合に、スクリプトにいくつかの追加の複雑さをもたらします。ただし、問題を回避することはできます。
また、お客様のデータベース管理者がNVARCHAR2のデータをサポートできないデータベース上の他のツールを使用したいと考えていることも認識していません。また、ツールが中断する可能性があるかどうかについては、実際には心配していません。必要に応じて他のツール。
顧客はデータを操作する別の方法を見つけることができると確信していますが、アプリケーションがエンタープライズレポーティングツールやエンタープライズETLツール、または経験したデスクトップツールとうまく連携しない場合は、その可能性が非常に高くなります。顧客がツールではなくアプリケーションのせいにすること。それはおそらくショーストッパーではないでしょうが、顧客に不必要に悲しみを与えることにもメリットはありません。それは彼らに競合他社の製品を使用するように駆り立てないかもしれませんが、それは彼らがあなたの製品を受け入れることを熱望することにはなりません。
wchar_tを使用してUTF-16を格納するアプリケーション（Visual C ++でコンパイルされている）が、処理されたすべてのデータに対してエンコード変換を実行する必要がある場合にも、パフォーマンスの低下が予想されますか？
あなたが話している「コンバージョン」が何なのかわかりません。これは、自分で文字セット変換を行うためにOracleのNLSレイヤーをバイパスしていると言っているかどうかについての私の最初の質問に戻る可能性があります。
しかし、私の結論は、あなたが説明していることを考えると、NCHAR/NVARCHAR2を使用することに何の利点も見当たらないということです。それらを使用することには多くの潜在的な欠点があります。特定のニーズとは無関係であるとして99％の欠点を取り除くことができたとしても、それでも、せいぜい2つのアプローチの間の洗浄であるという状況に直面しています。それを考えると、今後は柔軟性を最大化するアプローチを採用したいと思います。それは、データベース全体をUnicode（おそらく、AL32UTF8）に変換し、それを使用することです。