Oracle字段类型及存储（一）

       Oracle中2000个byte，并不是2000个字符的意思，1个字符在Oracle中可能是1个byte到4个byte不等，需看数据库字符集的设置了。

       对GBK字符集而言，ASCII码中128个字符使用1个字节进行存储，其它字符使用双字节存储；对UTF8字符集而言，ASCII码中128个字符使用1个字节进行存储，其它采用两个或三个字节进行存储，四个字节存储的是极少使用字符；

       数据库中有一个参数NLS_LENGTH_SEMANTICS，这个参数有两个取值CHAR和BYTE。当为CHAR时字符类型的长度是按字符个数来计算，而不是按BYTE来计算，这在使用变长字符集(AL32UTF8)的情况下非常有用，因为一个字符所占用的字节数是不定的，就给我们准确估计字段长度(BYTE)带来不便。

1、CHAR。

      CHAR存储定长数据很方便，CHAR字段上的索引效率级高，比如定义char(10)，那么不论你存储的数据是否达到了10个字节，都要占去10个字节的空间，不足的自动用空格填充。

2、VARCHAR

      VARCHAR存储变长数据，但存储效率没有CHAR高。如果一个字段可能的值是不固定长度的，我们只知道它不可能超过10个字符，把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么“+1”呢？这一个字节用于保存实际使用了多大的长度。从空间上考虑，用varchar合适；从效率上考虑，用char合适，关键是根据实际情况找到权衡点。

3、TEXT

      TEXT存储可变长度的非Unicode数据，最大长度为2^31-1(2,147,483,647)个字符。

4、NCHAR、NVARCHAR、NTEXT

      这三种从名字上看比前面三种多了个“N”。它表示存储的是Unicode数据类型的字符。我们知道字符中，英文字符只需要一个字节存储就足够了，但汉字众多，需要两个字节存储，英文与汉字同时存在时容易造成混乱，Unicode字符集就是为了解决字符集这种不兼容的问题而产生的，它所有的字符都用两个字节表示，即英文字符也是用两个字节表示。

5、字符集与国家字符集

       1>字符集
             (1)用来存储CHAR, VARCHAR2, CLOB, LONG等类型数据
             (2)用来标示诸如表名、列名以及PL/SQL变量等
             (3)用来存储SQL和PL/SQL程序单元等

       2>国家字符集

              (1)用以存储NCHAR, NVARCHAR2, NCLOB等类型数据
             (2)国家字符集实质上是为oracle选择的附加字符集，主要作用是为了增强oracle的字    符处理能力，因为NCHAR数据类型可以提供对亚洲使用定长多字节编码的支持，而数据 库字符集则不能。国家字符集在oracle9i中进行了重新定义，只能在unicode编码中的     AF16UTF16和UTF8中选择，默认值是AF16UTF16

 

 

字段类型	中文说明	限制条件	其它说明
CHAR	固定长度字符串	最大长度2000bytes
VARCHAR2	可变长度的字符串	最大长度4000bytes	可做索引的最大长度749
NCHAR	根据字符集而定的固定长度字符串	最大长度2000bytes
NVARCHAR2	根据字符集而定的可变长度字符串	最大长度4000bytes
DATE	日期(日-月-年)	DD-MM-YY(HH-MI-SS)	经过严格测试，无千虫问题
LONG	超长字符串	最大长度2G(231-1)	足够存储大部头著作
RAW	固定长度的二进制数据	最大长度2000bytes	可存放多媒体图象声音等
LONG RAW	可变长度的二进制数据	最大长度2G	同上
BLOB	二进制数据	最大长度4G
CLOB	字符数据	最大长度4G
NCLOB	根据字符集而定的字符数据	最大长度4G
BFILE	存放在数据库外的二进制数据	最大长度4G
ROWID	数据表中记录的唯一行号	10bytes	********.****.****格式，*为0或1
NROWID	二进制数据表中记录的唯一行号	最大长度4000bytes
NUMBER(P S)	数字类型	P为整数位，S为小数位
DECIMAL(P S)	数字类型	P为整数位，S为小数位
INTEGER	整数类型	小的整数
FLOAT	浮点数类型	NUMBER(38)，双精度
REAL	实数类型	NUMBER(63)，精度更高

 

 

转载于:https://www.cnblogs.com/emily_fly/archive/2012/02/28/2372613.html