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

Question

我们将迁移一个应用程序以使其支持Unicode,并且必须在整个数据库的unicode字符集或存储在N [VAR] CHAR2中的unicode列之间进行选择.

我们知道如果我们选择NVARCHAR2,我们将不再有可能使用Oracle Text索引列内容,因为Oracle Text只能根据CHAR类型索引列.

除此之外,从Oracle收获的可能性是否可能出现其他重大差异？

此外,是否有可能在较新版本的Oracle中添加一些新功能,但只支持CHAR列或NCHAR列,但不支持两者？

谢谢您的回答.

注意Justin的回答:

谢谢您的回答.我将讨论你的观点,适用于我们的案例:

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

我们还使用SQL*Loader和SQL*Plus与数据库通信以获取基本语句或在产品版本之间进行升级.我们还没有听说过有关NVARCHAR2的所有软件的任何具体问题.

我们也不知道我们客户中的数据库管理员想要在数据库上使用其他无法支持NVARCHAR2数据的工具,我们并不关心他们的工具是否可能会中断,毕竟他们都熟练工作并且可能会发现必要时还有其他工具.

你的最后两点对我们的案例更有洞察力.我们不使用Oracle的许多内置包,但它仍然会发生.我们将探讨这个问题.

如果我们wchar_t用于存储UTF-16 的应用程序(在Visual C++下编译)必须对所有已处理的数据执行编码转换,我们是否还会期望性能中断？

Answer 1

如果您有任何接近选择的内容,请为整个数据库使用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开发人员.

你是什​​么意思"照顾数据本身"？我希望你不是说你已经将你的应用程序配置为绕过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)并使用它.