数据库设计中char和long两种类型不要选择

如果用 char ，问题非常多： 1.可能浪费空间，除非正好放满。 2.会导致程序员在字段前使用trunc等截掉尾部空的函数，要优化必须建立一些函数索引。写程序还要用rpad之类的函数。 3.如果char很大，很可能导致索引无法建立。 4.长度一变，经常要修改程序。 5.

如果用char，问题非常多：
1.可能浪费空间，除非正好放满。
2.会导致程序员在字段前使用trunc等截掉尾部空格的函数，要优化必须建立一些函数索引。写程序还要用rpad之类的函数。
3.如果char很大，很可能导致索引无法建立。

4.长度一变，经常要修改程序。
5.导致程序使用大量的非绑定变量。这个可能更开发语言有关，例子：
c_id=‘1212’ 可以查询到结果
如果使用绑定：c_id=:a这个要看各种开发语言，因为不会补全尾部的空格，可能查询结果为空。

6.CHAR/NCHAR类型还会带来混乱（很多应用存储了信息之后却无法“找到”所存储的数据）。

还有：CHAR/NCHAR实际上只是伪装的VARCHAR2/NVARCHAR2，基于这一点，所以我认为其实只需要考虑这两种字符串类型：VARCHAR和NVARCHAR2。

Oracle的LONG类型可谓“臭名昭著”，由于LONG类型的限制太多，以至于Oracle很少去提LONG类型有哪些限制条件，而一般都是通过说明在哪些情况下，可以使用LONG类型。

正是这些限制阻止了LONG的使用，Oracle也在推出了大对象类型——LOB之后，强烈建议用户不要在使用LONG类型。

限制：

1、一个表中只能包含一个LONG类型的列。

2、不能索引LONG类型列。

3、不能将含有LONG类型列的表作聚簇。

4、不能在SQL*Plus中将LONG类型列的数值插入到另一个表格中,如insertinto ...select。

5、不能在SQL*Plus中通过查询其他表的方式来创建LONG类型列,如createtable as select。

6、不能对LONG类型列加约束条件（NULL、NOTNULL、DEFAULT除外），如：关键字列(PRIMARYKEY)不能是LONG数据类型。

7、LONG类型列不能用在Select的以下子句中：where、groupby、orderby，以及带有distinct的select语句中。

8、LONG类型列不能用于分布查询。

--整理自网络