今天接触到一个比较有意思的问题,常见到极易忽略,但又不经意间掉坑又不容易出来。
创建表:
CREATE TABLE TEMP_DECODE
(
BORROW_TYPE CHAR(1),
BORROW_TYPE1 CHAR(2),
BORROW_TYPE2 VARCHAR2(10),
BORROW_TYPE3 INT
)
执行SQL如下:
SELECT DECODE(BORROW_TYPE,'7','ABC','HELLO'),
DECODE(BORROW_TYPE1,'7','ABC','HELLO'),
DECODE(BORROW_TYPE1,7,'ABC','HELLO'),
DECODE(BORROW_TYPE2,'7','ABC','HELLO'),
DECODE(BORROW_TYPE3,'7','ABC','HELLO')
FROM TEMP_DECODE
您认为结果会是什么样子呢?
其实结果是这家伙,是否和您预想的一样呢?
此时我们想起来,我们都知道Char类型是定长的(掉坑里了吧),所以'7'在Char(2)类型中存储的肯定的不是'7'了,而是数据库又填补了一个字符,问题来了,填充的是什么呢?
其实是空格(""),如下这个SQL
SELECT DECODE(BORROW_TYPE,'7','ABC','HELLO'),
DECODE(BORROW_TYPE1,'7 ','ABC','HELLO'),--注意这个地方的空格
DECODE(BORROW_TYPE1,7,'ABC','HELLO'),
DECODE(BORROW_TYPE2,'7','ABC','HELLO'),
DECODE(BORROW_TYPE3,'7','ABC','HELLO')
FROM TEMP_DECODE
结果是:
这个问题虽不常见,但极容易掉坑,如果是枚举类型如(1,2,3,4..)之类的DB里面建议还是用smallint吧,如果是非字符的就用varchar2类型吧,char类型还是尽量少用。想象一下您本来CHAR(1)用的好好的,
结果别人把这个长度改成CHAR(2)了,您之前的SQL是不是直接就DUANG了(如果存储的都是数值您直接写成数值类型也可以的如第一个SQL,只是这个场景下我不知道您为什么不用smallint呢)?