Oracle Text 不适用于 NVARCHAR2。还有什么可能不可用？

Question

我们将迁移应用程序以使其支持 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，必须对所有处理过的数据进行编码转换？

Answer 1

如果您有任何选择，请为整个数据库使用 Unicode 字符集。总的来说，这样的生活会更加轻松。

• 有很多第三方实用程序和库根本不支持 NCHAR/NVARCHAR2 列，或者无法使使用 NCHAR/NVARCHAR2 列变得愉快。例如，当您闪亮的新报告工具无法报告您的 NVARCHAR2 数据时，这非常烦人。
• 对于自定义应用程序，使用 NCHAR/NVARCHAR2 列需要跳过一些使用 CHAR/VARCHAR2 Unicode 编码的列所不需要的障碍。例如，在 JDBC 代码中，您会不断地调用 Statement.setFormOfUse 方法。其他语言和框架会有其他陷阱；有些会比较有据可查，有些则比较少见。
• 许多内置软件包只接受（或返回）一个 VARCHAR2 而不是 NVARCHAR2。由于隐式转换，您仍然可以调用它们，但最终可能会遇到字符集转换问题。
• 一般而言，能够避免数据库中的字符集转换问题并将这些问题转移到数据库实际从客户端发送或接收数据的边缘，可以使开发应用程序的工作变得更加容易。调试由网络传输导致的字符集转换问题就足够了——找出当存储过程连接来自 VARCHAR2 和 NVARCHAR2 的数据并将结果存储在 VARCHAR2 中时，在通过网络发送之前，某些数据会损坏非常痛苦。

Oracle 为以下情况设计了 NCHAR/NVARCHAR2 数据类型使用不同的编码（即您有大量日语数据，您希望使用 NVARCHAR2 中的 UTF-16 编码而不是 UTF-8 编码来存储这些数据）。如果您不是这两种情况之一，而且听起来不像是，我会不惜一切代价避免使用 NCHAR/NVARCHAR2。

回复您的跟进

我们的应用程序通常单独在 Oracle 数据库并负责处理 数据本身。其他软件 连接到数据库仅限于 Toad、Tora 或 SQL 开发人员。

“处理数据本身”是什么意思？我希望您不是说您已将应用程序配置为绕过 Oracle 的字符集转换例程，并且您自己完成了所有字符集转换。

我还假设您正在使用某种 API/库来访问数据库，即使那是 OCI。您是否查看过需要对应用程序进行哪些更改以支持 NCHAR/NVARCHAR2 以及您使用的 API 是否支持 NCHAR/NVARCHAR2？您在 C++ 中获取 Unicode 数据这一事实实际上并不表明您不需要进行（可能是重大的）更改来支持 NCHAR/NVARCHAR2 列。

我们还使用 SQL*Loader 和 SQL*Plus 来 与数据库通信 基本报表或升级之间 产品的版本。我们还没有 听说有任何具体问题 那些关于 NVARCHAR2 的软件。

这些应用程序都使用 NCHAR/NVARCHAR2。 NCHAR/NVARCHAR2 在脚本中引入了一些额外的复杂性，特别是当您尝试对在数据库字符集中无法表示的字符串常量进行编码时。不过，您当然可以解决这些问题。

我们也不知道数据库 我们客户中的管理员 想用其他工具上 无法支持数据的数据库 在 NVARCHAR2 上，我们并不是真的 担心他们的工具是否可能 破坏，毕竟他们擅长 他们的工作，并且可能会找到其他工具，如果 必要的。

虽然我确信您的客户可以找到处理数据的其他方法，但如果您的应用程序不能很好地与他们的企业报告工具、企业 ETL 工具或他们碰巧使用过的任何桌面工具配合使用，客户很可能会责怪您的应用程序而不是他们的工具。它可能不会成为阻碍，但不必要地引起客户悲伤也没有任何好处。这可能不会促使他们使用竞争对手的产品，但不会让他们渴望接受您的产品。

我们是否也可以期待性能 如果我们的应用程序（即 在 Visual C++ 下编译），它使用 wchar_t 存储 UTF-16，必须 对所有执行编码转换 处理过的数据？

我不确定您在说什么“转化”。这可能会回到我最初的问题，即您是否说您正在绕过 Oracle 的 NLS 层自行进行字符集转换。

不过，我的底线是，鉴于您所描述的内容，我认为使用 NCHAR/NVARCHAR2 没有任何优势。使用它们有很多潜在的缺点。即使您可以消除与您的特定需求无关的 99% 的缺点，但是，您仍然面临这样一种情况，即充其量只是两种方法之间的过渡。鉴于此，我更愿意采用能够最大限度提高未来灵活性的方法，即将整个数据库转换为 Unicode（大概是 AL32UTF8）并使用它。