通常のselect文とトリガの結果が異なるcount（*）

Question

SQLDeveloperで奇妙な問題が発生しています。

私はのように、通常のselect文を持っている：SELECT COUNT(*) FROM demo WHERE NAME='ABC ';同様の結果1を与える：SELECT COUNT(*) FROM demo WHERE NAME='ABC'; 上記のクエリはと同じ選択クエリを実行した結果1. ができます。 2番目のクエリで余分に追加されたスペースは、カウント値を変更しないことに注意してください。

トリガー内でcount（*）文を使用すると、異なるカウント結果が得られ、カウントを評価する際にスペースを考慮します。 なぜこれが起こっているのですか？ SQLDeveloperバージョン4.1.5.21を使用しています。あなたの列がcharいうよりvarchar2であれば

Answer 1

あなたはこれを見ることができます：あなたが引き金で、まったく同じクエリを実行すると

create table demo (name char(9)); 

insert into demo values ('ABC'); 

1 row inserted. 

SELECT COUNT(*) FROM demo WHERE NAME='ABC'; 

    COUNT(*) 
---------- 
     1 

SELECT COUNT(*) FROM demo WHERE NAME='ABC  '; 

    COUNT(*) 
---------- 
     1 

- または任意のPL/SQLブロック - あなたが得る同じテキストリテラルを使用して同じ結果：あなたはリテラルテキストの代わりに値を供給するvarchar2変数を使用する場合

set serveroutput on 
declare 
    n number; 
begin 
    SELECT COUNT(*) into n FROM demo WHERE NAME='ABC'; 
    dbms_output.put_line(n); 
    SELECT COUNT(*) into n FROM demo WHERE NAME='ABC  '; 
    dbms_output.put_line(n); 
end; 
/

1 
1 

PL/SQL procedure successfully completed. 

しかし、あなたは別のカウントを取得：

declare 
    n number; 
    v varchar2(9); 
begin 
    v := 'ABC'; 
    SELECT COUNT(*) into n FROM demo WHERE NAME=v; 
    dbms_output.put_line(n); 
    v := 'ABC  '; 
    SELECT COUNT(*) into n FROM demo WHERE NAME=v; 
    dbms_output.put_line(n); 
end; 
/

0 
1 

PL/SQL procedure successfully completed. 

リテラルit is treated as a charテキストを使用する場合：式と条件の中で

• を彼らは空白埋め比較セマンティクスを使用してそれらを比較することによって、データ型CHARを持っているかのように、Oracleはテキスト・リテラルを扱います。

見かけの挙動差は、ダウンblank-padded and nonpadded comparison semanticsに来る：空白埋めセマンティクスで

、二つの値の長さが異なる場合、Oracleは最初の短い方の末尾に空白が追加されますそれらの長さは等しい。
...
比較の1つまたは両方の値にVARCHAR2またはNVARCHAR2のデータ型がある場合、Oracleは非埋め込みの比較セマンティクスを使用します。リテラル（char）のテキストを使用してchar列を比較すると

、両方が同じ長さに埋められ、その両方の条件が真と評価されています。空白埋めのセマンティクスでは、'ABC'、'ABC '、'ABC 'などはすべて同等です。

charの列とvarchar2の変数を比較すると、実際の列の値とまったく同じ長さに手作業で埋められた2番目の条件だけが真と評価されます。パディングされた列の値'ABC 'は、明示的に同じに設定されている場合にのみ変数に一致します。それはちょうど'ABC'またはそれ以外のものと等しくはありません。

テキスト列にvarchar2を使用すると、これらの奇妙さを避けることが一般にはるかに簡単です。固定長の文字列を使用する必要があるのは私の経験では珍しいことですが、データの長さが変わる場合は、varchar2は柔軟性が高く、ストレージを少なくします。