INT类型是NUMBER类型的子类型。
下面简要说明：
（1）NUMBER（P,S）
该数据类型用于定义数字类型的数据，其中P表示数字的总位数（最大字节个数），而S则表示小数点后面的位数。假设定义SAL列为NUMBER（6,2）则整数最大位数为4位（6-2=4），而小数最大位数为2位。
（2）INT类型
当定义整数类型时，可以直接使用NUMBER的子类型INT，顾名思义：INT用于整型数据。
oracle本来就没有int类型，为了与别的数据库兼容，新增了int类型作为number类型的子集。
int类型只能存储整数;
number可以存储浮点数，也可以存储整数；
number(8,1)存储小数位为1位，总长度为8的浮点数，如果小数位数不足，则用0补全；
number(8)存储总长度为8的整数；
int相当于number(22),存储总长度为22的整数。
举例说明：
--创建表结构
SQL> create table tab(id0 int,id1 number,id2 number(8,1),id3 number(8));
Table created
SQL>
--插入测试数据
SQL> insert into tab select 1,1.5,1.6,8 from dual;
1 row inserted
SQL> insert into tab select 1,1.55,1.6,8 from dual;
1 row inserted
SQL> insert into tab select 1,1.595,1,8 from dual;
1 row inserted
SQL> commit;
Commit complete
SQL> select * from tab;
ID0 ID1 ID2 ID3
---------- ---------- ---------- ---------
1 1.5 1.6 8
1 1.55 1.6 8
1 1.595 1.0 8
--查询数据字典表dba_tab_columns
SQL> select table_name,column_name,data_type,data_length,data_precision,data_scale from dba_tab_columns a
2 where table_name=‘TAB‘
3 and owner=‘NETMAX‘
4 order by column_id;
TABLE_NAME COLUMN_NAME DATA_TYPE DATA_LENGTH DATA_PRECISION DATA_SCALE
--------------- -------------- ----------------- ---------------- ----------- ----------
TAB ID0 NUMBER 22 0
TAB ID1 NUMBER 22
TAB ID2 NUMBER 22 8 1
TAB ID3 NUMBER 22 8 0
SQL>
在dba_tab_columns表中，
Data_type表示字段类型；
Data_length表示字段类型的长度；
Data_Precision表示字段类型的精度的总长度，如果为null,表示精度的总长度不固定，最长为Data_Length；
Data_scale表示字段类型的精度范围，如果为0,表示只能存储为整数，
如果为null,表示可以存储整数或者浮点数，浮点数位数不确定，
如果为整数，表示存储的精度位数。
查询dba_tab_columns表，发现tab表中ID0字段类型int已经被转换为number(22)。
来源：http://blog.csdn.net/ojuju10/article/details/4576446
----------------------------------------------------------------------------------------------------------------
Oracle中NVARCHAR2与VARCHAR2的区别
VARCHAR2是Oracle提供的特定数据类型，Oracle可以保证VARCHAR2在任何版本中该数据类型都可以向上和向下兼容。
VARCHAR在Oracle中不建议使用。
具体到NVARCHAR2和VARCHAR2的区别，从使用角度来看区别在于：NVARCHAR2在计算长度时和字符集相关的，例如数据库是中文字符集时以长度10为例，则
1、NVARCHAR2(10)是可以存进去10个汉字的，如果用来存英文也只能存10个字符。
2、而VARCHAR2(10)的话，则只能存进5个汉字，英文则可以存10个。
来源：http://www.cnblogs.com/flyingfish/archive/2010/01/15/1648448.html