如果您有任何选择，请为整个数据库使用 Unicode 字符集。总的来说，这样的生活会更加容易。
- 有很多第三方实用程序和库根本不支持 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-16 编码而不是 UTF-8 编码来存储这些数据）。如果您不在这两种情况之一，而且听起来不像，我会不惜一切代价避免使用 NCHAR/NVARCHAR2。
回应您的跟进
我们的应用程序通常单独在 Oracle 数据库上，并自行处理数据。其他连接数据库的软件仅限于 Toad、Tora 或 SQL developer。
您是什么意思“处理数据本身”？我希望您不是说您已将应用程序配置为绕过 Oracle 的字符集转换例程，并且您自己完成了所有字符集转换。
我还假设您正在使用某种 API/库来访问数据库，即使那是 OCI。您是否查看过需要对应用程序进行哪些更改以支持 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% 的缺点，但是，您仍然面临这样一种情况，即充其量只是两种方法之间的过渡。鉴于此，我更愿意采用能够最大限度提高灵活性的方法，即将整个数据库转换为 Unicode（大概是 AL32UTF8）并使用它。