OracleTextはNVARCHAR2では機能しません。他に何が利用できない可能性がありますか？
アプリケーションを移行してUnicodeをサポートし、データベース全体のUnicode文字セットを選択するか、N [VAR] CHAR2に格納されているUnicode列を選択する必要があります。
Oracle TextはCHARタイプに基づいてのみ列に索引を付けることができるため、NVARCHAR2を選択した場合、OracleTextを使用して列の内容に索引を付ける可能性がなくなることがわかっています。
それとは別に、オラクルの可能性から収穫するときに他の大きな違いが生じる可能性がありますか？
また、Oracleの新しいバージョンでいくつかの新機能が追加されている可能性がありますが、CHAR列またはNCHAR列のいずれかのみをサポートし、両方はサポートしていませんか？
ご回答ありがとうございます。
ジャスティンの答えに従うことに注意してください：
ご回答ありがとうございます。私たちのケースに適用されるあなたのポイントについて説明します：
私たちのアプリケーションは通常、Oracleデータベース上に単独で存在し、データ自体を処理します。データベースに接続するその他のソフトウェアは、Toad、Tora、またはSQL開発者に限定されています。
また、SQL * LoaderおよびSQL * Plusを使用して、基本的なステートメントのためにデータベースと通信したり、製品のバージョン間でアップグレードしたりします。 NVARCHAR2に関して、これらすべてのソフトウェアに特定の問題があることは聞いたことがありません。
また、お客様のデータベース管理者がNVARCHAR2のデータをサポートできないデータベース上の他のツールを使用したいと考えていることも認識していません。また、ツールが中断する可能性があるかどうかについては、実際には心配していません。必要に応じて他のツール。
最後の2つのポイントは、私たちのケースにとってより洞察に満ちています。 Oracleの組み込みパッケージはあまり使用していませんが、それでも発生します。その問題を調査します。
wchar_tを使用してUTF-16を格納するアプリケーション（Visual C++でコンパイルされている）が、処理されたすべてのデータに対してエンコード変換を実行する必要がある場合にも、パフォーマンスの低下が予想されますか？
選択肢に近いものがある場合は、データベース全体に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）に変換し、それを使用することです。