标签：
今天接触到一个比较有意思的问题,常见到极易忽略,但又不经意间掉坑又不容易出来。
创建表：
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呢)？
标签：
原文地址：http://www.cnblogs.com/wangn/p/4901774.html
