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