我们知道，如果我们选择NVARCHAR2，我们将不再有可能使用Oracle Text索引列内容，因为Oracle Text只能基于CHAR类型对列进行索引。
此外，从Oracle的可能性收获可能会出现其他主要差异？
此外，在较新版本的Oracle中是否可能添加了一些新功能，但是仅支持CHAR列或NCHAR列，但不支持两者。
谢谢你的答案。
注意Justin的回答：
谢谢您的回答。我会讨论你的观点，适用于我们的案例：
我们的应用程序通常是在Oracle数据库上单独处理的
数据本身。连接到数据库的其他软件仅限于Toad，
Tora或sql开发人员。
我们还使用sql * Loader和sql * Plus与数据库进行基本通信
语句或产品版本升级。我们有
没有听说有关NVARCHAR2的所有软件的任何具体问题。
我们也不知道我们的客户中的数据库管理员会
喜欢在数据库上使用其他不能支持数据的工具
NVARCHAR2，我们并不关心他们的工具是否会中断，
毕竟他们熟练的工作，如有必要，可能会找到其他工具。
你的最后两点对我们的情况更有见地。我们不用很多
来自Oracle的内置软件包，但它仍然发生。我们会探讨一下
问题。
如果我们的应用程序(在Visual C下编译)使用wchar_t，我们也可以期待性能的破坏
存储UTF-16，必须对所有处理的数据执行编码转换？
>有很多第三方实用程序和库，根本不支持NCHAR / NVARCHAR2列，或者不能使NCHAR / NVARCHAR2列工作愉快。这是非常烦人的，例如，当您闪亮的新的报告工具无法报告您的NVARCHAR2数据。
>对于自定义应用程序，使用NCHAR / NVARCHAR2列需要跳过一些使用CHAR / VARCHAR2 Unicode编码列的环。例如，在JDBC代码中，您将不断调用Statement.setFormOfUse方法。其他语言和框架也会有其他的障碍;一些文件相对较为详细，其他一些将相对晦涩难懂。
许多内置程序包只能接受(或返回)VARCHAR2而不是NVARCHAR2。您仍然可以通过隐式转换来调用它们，但您可能会遇到字符集转换问题。
>通常，能够避免数据库内的字符集转换问题，并将这些问题降级到数据库实际从客户端发送或接收数据的边缘，使开发应用程序的工作变得更加容易。调试由网络传输引起的字符集转换问题是足够的工作 – 在存储过程从VARCHAR2和NVARCHAR2连接数据并将结果存储在VARCHAR2中之前，通过网络发送之前，会发现有些数据被破坏令人难过
Oracle设计了NCHAR / NVARCHAR2数据类型，用于尝试支持不支持使用Unicode的新应用程序在同一数据库中不支持Unicode的旧版应用程序的情况，以及有利于将某些Unicode数据存储在不同的情况下编码(即，您有大量的日语数据，您希望在NVARCHAR2而不是UTF-8编码中使用UTF-16编码存储)。如果你不是在这两种情况之一，而且听起来不像你，我将不惜一切代价避免NCHAR / NVARCHAR2。
回应你的跟进
Our application is usually alone on
@H_403_53@
the Oracle database and takes care of
the data itself. Other software that
connect to the database are limited to
Toad,Tora or sql developer.你是什么意思“照顾数据本身”？我希望你不是说你已经配置了你的应用程序来绕过Oracle的字符集转换例程，并且你自己完成所有的字符集转换。
我也假设你正在使用某种API /库访问数据库，即使是OCI。您是否查看了需要对应用程序进行哪些更改以支持NCHAR / NVARCHAR2以及您使用的API是否支持NCHAR / NVARCHAR2？您在C中获取Unicode数据的事实并不表示您不需要进行(潜在的重大)更改来支持NCHAR / NVARCHAR2列。
We also use sql*Loader and sql*Plus to
@H_403_53@
communicate with the database for
basic statements or to upgrade between
versions of the product. We have not
heard of any specific problem with all
those software regarding NVARCHAR2.这些应用程序都使用NCHAR / NVARCHAR2。 NCHAR / NVARCHAR2在脚本中引入一些额外的复杂性，特别是如果您尝试编码在数据库字符集中无法表示的字符串常量。你一定可以解决问题。
We are also not aware that database
@H_403_53@
administrators among our customers
would like to use other tools on the
database that could not support data
on NVARCHAR2 and we are not really
concerned whether their tools might
disrupt,after all they are skilled in
their job and may find other tools if
necessary.虽然我确信您的客户可以找到使用数据的替代方法，但如果您的应用程序不能很好地利用企业报表工具或企业ETL工具或者他们遇到的任何桌面工具，很有可能客户会责怪你的应用程序，而不是他们的工具。这可能不会是一个节目停止，但也不会造成客户不必要的悲伤也没有好处。这可能不会促使他们使用竞争对手的产品，但不会让他们渴望拥抱您的产品。
Could we also expect performance
@H_403_53@
breakage if our application (that is
compiled under Visual C++),that uses
wchar_t to store UTF-16,has to
perform encoding conversions on all
processed data?我不知道你在说什么“转换”。这可能会回到我最初的问题，您是否表示您正在绕过Oracle的NLS层，以自己进行字符集转换。
我的底线是，我没有看到使用NCHAR / NVARCHAR2给出你正在描述的任何优势。使用它们有很多潜在的缺点。然而，即使您可以消除99％的缺点与您的特定需求无关，您仍然面临着两种方法之间的冲洗。鉴于此，我宁可采用最大化灵活性的方法，而将整个数据库转换为Unicode(推测为AL32UTF8)，并将其用于此。
