N功能可以导致现有查询出现问题吗?

Tee*_*jay 7 oracle unicode bulkinsert

我们使用Oracle 10gOracle 11g.

我们还有一个层来自动编写查询,来自.net编写的伪SQL代码(类似于SqlAlchemy for Python).

我们的层当前用单引号包装任何字符串',如果包含非ANSI字符,它会自动组成UNISTR带有unicode字节的特殊字符(如\00E0).

现在我们创建了一个使用以下构造进行多次插入的方法:
INSERT INTO ... (...) SELECT ... FROM DUAL UNION ALL SELECT ... FROM DUAL ...

此算法可以组成查询,其中有时会传递相同的字符串字段'my simple string',有时会将其包装为UNISTR('my string with special chars like \00E0').

所述条件导致a ORA-12704: character set mismatch.

一种解决方案是使用该INSERT ALL构造,但与现在使用的构造相比,它非常慢.

另一个解决方案是指示我们的图层放在N任何字符串的前面(已经包裹的字符串除外UNISTR).这很简单.

我只是想知道这是否会对现有查询造成任何副作用.

注意:DB上的所有字段都是NCHARNVARCHAR2.


Oracle参考:http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch7progrunicode.htm

Nei*_*ema 2

基本上你要问的是,使用或不使用 N 函数存储字符串的方式是否有区别。

您可以自己检查考虑:

SQL> create table test (val nvarchar2(20));

Table TEST created.

SQL> insert into test select n'test' from dual;

1 row inserted.

SQL> insert into test select 'test' from dual;

1 row inserted.

SQL> select dump(val) from test;
DUMP(VAL)                                                                      
--------------------------------------------------------------------------------
Typ=1 Len=8: 0,116,0,101,0,115,0,116                                            
Typ=1 Len=8: 0,116,0,101,0,115,0,116  
Run Code Online (Sandbox Code Playgroud)

如您所见,完全相同,因此没有副作用。

之所以如此完美,是因为 unicode 的优雅

如果您有兴趣,这里有一个很好的视频解释它

https://www.youtube.com/watch?v=MijmeoH9LT4

  • “在字符串文字上到处应用 N 会导致性能下降吗?” 不,不能,因为插入 nchar 列的任何 char 值都会隐式或显式转换为 nchar。 (2认同)