db2数据库把char类型直接改成varchar类型吗
展开全部
在数据库设计的时候,VARCHAR和CHAR类型之间的使用,我和小唐发生了分歧。
我坚持要对表中的某些列,比如个性签名,使用CHAR型的来存储字符串信息。因为我认为使用CHAR一方面在数据库检索起来速度更快,同时在使用COBOL程序在逻辑上处理CHAR字符串生成的变量的时候,也相对简单,只要直接给变量赋值就可以了,这样子也便于程序的处理。而如果使用使用那个VARCHAR的话,数据检索效率相对低,而在COBOL中需要首先给字符串的长度赋值,然后在给它的内容赋值。这样子加大了程序的逻辑处理过程。还带来了一定的风险,比如赋值的时候,如果赋值的长度超过了最大的值,就会使得程序执行的时候出现意想不到的后果。
而他认为,他使用CHAR类型,很容易浪费存储空间,因为如果使用CHAR,无论存储的字符串内容的长度是多长,都会使用它固定长度去存储它。而使用VARCHAR则可以根据它实际的字符串长度去存储数据。这个是VARCHAR类型最大的特点,也是它到现在在数据库技术中还能存在的根本原因。
我开始对自己的想法变得有点怀疑。后来,我去网上找了找相关的资料,得知:
1,如果希望列中的数据值大小接近一致,请使用char;如果希望列中的数据值大小显著不同,请使用varchar。
2,事实上,因为char类型通常要比varchar类型占用更多的空间,所以从减少空间占用量和减少磁盘i/o的角度,使用varchar类型反而更有利
3,当数据的长度相差较大时,使用char会浪费很多的空间,而使用varchar可以节约大量的空间,对于数据量比较大的情况,更能体现出两者的差异。当数据长度比较固定(相差较小或固定不变)时,两者的差别就不太大。
4,在查询时,由于存储方式上的不同,导致char字段的查询速度要好于varchar字段,特别是对于在极大量的数据中查询。
综合上述因素,我采取了他的做法。后来才知道,其实,那些东西都已经是约定俗成了的。对于较长的字符串就是应该使用VARCHAR类型。看来自己还是有很多的东西值得去学习,而不是片面地从程序处理逻辑上来理解,判断。
我坚持要对表中的某些列,比如个性签名,使用CHAR型的来存储字符串信息。因为我认为使用CHAR一方面在数据库检索起来速度更快,同时在使用COBOL程序在逻辑上处理CHAR字符串生成的变量的时候,也相对简单,只要直接给变量赋值就可以了,这样子也便于程序的处理。而如果使用使用那个VARCHAR的话,数据检索效率相对低,而在COBOL中需要首先给字符串的长度赋值,然后在给它的内容赋值。这样子加大了程序的逻辑处理过程。还带来了一定的风险,比如赋值的时候,如果赋值的长度超过了最大的值,就会使得程序执行的时候出现意想不到的后果。
而他认为,他使用CHAR类型,很容易浪费存储空间,因为如果使用CHAR,无论存储的字符串内容的长度是多长,都会使用它固定长度去存储它。而使用VARCHAR则可以根据它实际的字符串长度去存储数据。这个是VARCHAR类型最大的特点,也是它到现在在数据库技术中还能存在的根本原因。
我开始对自己的想法变得有点怀疑。后来,我去网上找了找相关的资料,得知:
1,如果希望列中的数据值大小接近一致,请使用char;如果希望列中的数据值大小显著不同,请使用varchar。
2,事实上,因为char类型通常要比varchar类型占用更多的空间,所以从减少空间占用量和减少磁盘i/o的角度,使用varchar类型反而更有利
3,当数据的长度相差较大时,使用char会浪费很多的空间,而使用varchar可以节约大量的空间,对于数据量比较大的情况,更能体现出两者的差异。当数据长度比较固定(相差较小或固定不变)时,两者的差别就不太大。
4,在查询时,由于存储方式上的不同,导致char字段的查询速度要好于varchar字段,特别是对于在极大量的数据中查询。
综合上述因素,我采取了他的做法。后来才知道,其实,那些东西都已经是约定俗成了的。对于较长的字符串就是应该使用VARCHAR类型。看来自己还是有很多的东西值得去学习,而不是片面地从程序处理逻辑上来理解,判断。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询
广告 您可能关注的内容 |