发现织梦的数据库中，字符60以下的，全是char型？而不是varchar型，合理吗?

Question

发现织梦的数据库中，字符60以下的，全是char型？而不是varchar型，
我的点不解，为何不用varchar呢？
当然，我知道 char 的性能比 varchar 要高些，但是我想，不会太明显吧。
比如“标题”字段，织梦中是 char(60),为何不设成varchar(60)呢？这里少很多空间呀？我现在的原则是，10个字符以下的用 char型，超过 20 个字符的，都用 varchar 型，
我的作法不好吗？大家谈谈

Answer 1

很明显，固定长度记录的表比非固定长度记录的表快上Ｎ倍。空间与时间的平衡。　想一下为什么不压缩了存贮呢？那样岂不是更省空间？没有好坏之说，不同的应用情况下，不同的处理。比如我的硬盘足够大，内存足够多，全选char也没什么。

Answer 2

还有一点， char 型，实际上会有很多空格呀。
前台处理时，要做截去空格的操作，而 varchar 就方便多了，没有多余的空格。

Answer 3

定长字符串主要是方便了存储，定位这个字段非常方便。所以，这是一种权衡。一般而言，如果浪费空间在20%以内，使用char(*)型是可以原谅的。太多了，可能就要考虑使用varchar(*)，也有30%-70%原则的。

Answer 4

varchar是不用截空格，但是要额外计算长度

Answer 5

织梦是什么东东？没接触过。如果综合考虑的话，字符串统一用NVARCHAR是比较好的。说定长比变长快N倍的，可能有点想当然了。要看数据库是采用什么技术的，就是拿以前的MS SQL2000来说，我们公司由于字符集兼容，有一次把全部的CHAR换成NVARCHAR，并没有感觉什么慢，N倍就更谈不上了。对于像SQLITE这样用B-TREE的数据库来说，内部本身就是变长的，就是说你设计个定长的CHAR，他还是按变长处理的。这个更加不可能有丝毫的加速。MYSQL也是采用B-TREE的，但是没有深入了解就不好说了。最好还是实地测试一下。空间换时间不是泛泛之谈，否则空间是花掉了，时间同样浪费掉了。没有统一的原则，要看具体实例你说10个字符以上用VARCHAR，那么条码这种字段用VARCHAR显然没什么意义。

Answer 6

没有统一的原则，要看具体实例你说10个字符以上用VARCHAR，那么条码这种字段用VARCHAR显然没什么意义。
---------------------------------
当然有最基本的原则，定义一定要 char

Answer 7

CHAR和VARCHAR各有忧虑，不要笼统的说谁比谁的性能高。