私はこのように私のSQLのwhere句でいくつかのCHARデータを比較しています、
ここで、PRI_CODE <PriCode
私が抱えている問題は、CHAR値の長さが異なる場合です。したがって、PRI_CODE='0800'およびPriCode='20'の場合、falseではなくtrueを返します。
このように比較しているようです
'08' < '20'
の代わりに
'0800' < '20'
CHAR比較は、左から開始して、いずれかの値が終了するまでですか？
もしそうなら、どうすればこれを修正できますか？
私の値には文字を含めることができるので、数値に変換することはできません。
'08' と '20' を比較しているのではなく、ご想像のとおり、'0800' と '20' を比較しています。
ただし、'0800' (文字列) が実際には '20' (文字列) よりも小さいことは予想していないようです。
数値比較のために数値に変換することが問題外である場合は、次の DB2 関数を使用できます。
right ('0000000000'||val,10)
これvalにより、左側にゼロが埋め込まれてサイズが 10 になります (CHAR(10)たとえば、 a に最適です)。これにより、フィールドが同じサイズであり、特定のケースで比較が機能することが少なくとも保証されます。しかし、私はあなたが物事をどのように行っているかを再考することをお勧めします: 行ごとの関数は、パフォーマンスの面でうまくスケーリングすることはめったにありません.
z/OS を使用している場合は、数人の DBA がコンピューター室の床に横になって仕事を待っているはずです。おそらく、そのうちの 1 人に特定のアプリケーションに合わせたアドバイスを求めることができます :-)
PRI_CODE_PADDED挿入/更新トリガーとセカンダリ列を使用して、完全にパディングされた列を保持するときに頭に浮かぶことの 1 つPRI_CODE(上記と同じ方法を使用)。PriCodeを実行する前に、変数が同様にフォーマットされていることを確認してくださいselect ... where PR_CODE_PADDED < PriCode。
挿入/更新時にそのコストが発生すると、実行する可能性が高いすべての選択で償却され (行ごとの関数を使用しなくなったため、非常に高速になります)、全体的なパフォーマンスが向上します (もちろん、データベースは、読み取りよりも書き込みが多い、信じられないほどまれな獣の 1 つではありません)。