我们将迁移一个应用程序以使其支持Unicode，并且必须在整个数据库的Unicode字符集或存储在N [VAR] CHAR2中的Unicode列之间进行选择。
我们知道，如果选择NVARCHAR2，就不再可能使用Oracle Text为列内容建立索引，因为Oracle Text只能基于CHAR类型对列进行索引。
除此之外，从Oracle的可能性中收获时是否可能还会出现其他主要差异？
另外，是否可能在较新的Oracle版本中添加了一些新功能，但仅支持CHAR列或NCHAR列，但不同时支持这两个列？
谢谢您的回答。
请注意贾斯汀的回答:
谢谢您的回答。我将讨论您的观点，并适用于我们的案例:
我们的应用程序通常单独存在于Oracle数据库上，并负责
数据本身。其他连接到数据库的软件仅限于Toad，
Tora或SQL开发人员。
我们还使用SQL * Loader和SQL * Plus与数据库进行通信，以进行基本
声明或在产品版本之间进行升级。我们有
没有听说所有有关NVARCHAR2的软件存在任何特定问题。
我们也不知道客户中的数据库管理员会
喜欢在数据库上使用其他工具，这些工具无法支持
NVARCHAR2，我们并不真正担心它们的工具是否会中断，
毕竟，他们在工作上很熟练，并在必要时可以找到其他工具。
您的最后两点对于我们的案例更具洞察力。我们不使用很多
Oracle提供的内置软件包，但仍然会发生。我们将探索
问题。
如果我们的应用程序(使用Visual C++编译)使用wchar_t来执行操作，我们是否也可能会导致性能破坏？
存储UTF-16，必须对所有处理的数据执行编码转换吗？
最佳答案
如果您有其他选择，请对整个数据库使用Unicode字符集。这样总的来说，生活简直就是令人眼花easier乱。
Oracle设计了NCHAR / NVARCHAR2数据类型，用于以下情况:您试图与使用Unicode的新应用程序在同一数据库中支持不支持Unicode的遗留应用程序，并且对于以不同的方式存储某些Unicode数据的情况是有利的编码(即，您希望使用NVARCHAR2中的UTF-16编码而不是UTF-8编码存储大量日语数据)。如果您不处于这两种情况之一，并且听起来不像您那样，那么我将不惜一切代价避免使用NCHAR / NVARCHAR2。
回应您的跟进
您是什么意思“照顾数据本身”？我希望您不是在说您已将应用程序配置为绕过Oracle的字符集转换例程，而是自己进行所有字符集转换。
我还假设您正在使用某种API /库来访问数据库，即使那是OCI。您是否研究过需要对应用程序进行哪些更改以支持NCHAR / NVARCHAR2，以及您使用的API是否支持NCHAR / NVARCHAR2？在C++中获取Unicode数据的事实实际上并不表示您不需要进行更改(可能很重要)以支持NCHAR / NVARCHAR2列。
这些应用程序都可以与NCHAR / NVARCHAR2一起使用。 NCHAR / NVARCHAR2在脚本中引入了一些额外的复杂性，尤其是当您尝试编码数据库字符集中无法表示的字符串常量时。不过，您当然可以解决这些问题。
虽然我确定您的客户可以找到其他处理数据的方法，但是如果您的应用程序不能很好地与他们的企业报告工具，企业ETL工具或碰巧遇到过的任何桌面工具配合使用，则很有可能客户将责备您的应用程序而不是他们的工具。它可能不会成为秀场停止者，但不必要地引起客户悲痛也没有任何好处。这可能不会促使他们使用竞争对手的产品，但不会使他们渴望拥抱您的产品。
我不确定您在说什么“转换”。这可能会回到我最初的问题，即您是否要绕过Oracle的NLS层自行进行字符集转换。
不过，我的底线是，根据您的描述，使用NCHAR / NVARCHAR2不会带来任何好处。使用它们有很多潜在的缺点。即使您可以消除与您的特定需求无关的99％的缺点，但是，您仍然面临着一种充其量只是两种方法之间的冲刺的情况。鉴于此，我宁愿采用最大程度地提高灵活性的方法，也就是将整个数据库转换为Unicode(大概是AL32UTF8)并使用它。
关于oracle - Oracle Text不适用于NVARCHAR2。还有什么可能不可用？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4401043/