关于VARCHAR Vs的问题CHAR字段 [英] Question about VARCHAR Vs. CHAR fields
问题描述
您好，
我对VARCHAR字段有疑问。我们这里的应用程序组
开始更频繁地使用VARCHAR。甚至VARCHAR（2）到
（9）长度字段。他们说这是因为某些应用程序
程序，特别是Java Bean无法处理CHAR字段中
值后的空格。
是否有其他人看到这种趋势？
我知道VARCHAR字段有2个额外字节的开销。有没有人
知道由于跟踪长度，DML对这些
字段是否有显着的性能影响？
谢谢提前获取任何和所有信息，
杰夫
jdokos写道：< blockquote class =post_quotes>您好，
我对VARCHAR字段有疑问。我们的应用程序组开始更频繁地使用VARCHAR。甚至VARCHAR（2）到
（9）长度字段。他们说这是因为一些应用程序的程序，特别是Java Bean无法处理CHAR字段中
值之后的空格。
是否还有其他人看到这种趋势？ />
我知道VARCHAR字段有2个额外字节的开销。有没有人知道由于跟踪长度，DML对这些
字段是否有显着的性能影响？
有额外的存储空间你提到的开销，加上这可以导致行溢出和/或页面重组的性能问题。
IMO，这通常是懒惰的症状程序员而不是
应用程序无法处理额外的空间。
Ian写道：jdokos写道：
您好，
我对VARCHAR字段有疑问。我们的应用程序组开始更频繁地使用VARCHAR。甚至VARCHAR（2）到
（9）长度字段。他们说这是因为一些应用程序的程序，特别是Java Bean无法处理CHAR字段中
值之后的空格。
是否还有其他人看到这种趋势？ />
我知道VARCHAR字段有2个额外字节的开销。有没有人知道由于跟踪长度，DML对这些
字段是否会对性能产生重大影响？
如您所述，还有额外的存储开销，加上这可能导致行溢出和/或页面重组的性能问题。
IMO，这通常是懒惰程序员的症状，而不是
应用程序可以处理多余的空格。
在Informix中，VARCHAR占用的空间是多少？在
Oracle中浪费空间和CPU需要使用CHAR和
它几乎完全被放弃了。
谢谢。
-
Daniel A. Morgan
http://www.psoug.org
da ****** @ x.washington.edu
（将x替换为x以回复）
" DA Morgan" <哒****** @ psoug.org>写了
在Informix中，VARCHAR占用的空间是否比CHAR多？
完全没有。在开始时只需要一个字节来记录长度。
在Oracle中浪费空间和CPU需要使用CHAR和
几乎完全放弃了。
和informix一样，除了长度为char（15）（有人说甚至20）
char中的性能提升值得空间浪费了。所以我总是建议
a char字段到char（15）。
char和varchar之间的区别在删除和加载表中变得非常明显。
那是定期清理和再次加载的表。具有固定长度
列（char，int，date等）的表加载速度比使用可变长度表快得多。我认为
它与引擎计算有关，然后插入
行适合的页面。
Hello,
I have a question about VARCHAR fields. Our application groups here
are starting to use VARCHARs much more frequently. Even VARCHAR (2) to
(9) length fields. They say this is because some of the application
programs, specifically Java Beans cannot handle the spaces after the
value in CHAR fields.
Is anyone else seeing this trend?
I know that VARCHAR fields have 2 extra bytes of overhead. Does anyone
know if there is a significant performance impact in DML against these
fields due to tracking the length?
Thanks in advance for any and all information,
Jeff
jdokos wrote:Hello,
I have a question about VARCHAR fields. Our application groups here
are starting to use VARCHARs much more frequently. Even VARCHAR (2) to
(9) length fields. They say this is because some of the application
programs, specifically Java Beans cannot handle the spaces after the
value in CHAR fields.
Is anyone else seeing this trend?
I know that VARCHAR fields have 2 extra bytes of overhead. Does anyone
know if there is a significant performance impact in DML against these
fields due to tracking the length?
There is the additional storage overhead as you mention, plus this can
lead to performance issues with row overflows and/or page reorgs.
IMO, this is usually a symptom of lazy programmers rather than "the
app can''t handle extra spaces".
Ian wrote:jdokos wrote:Hello,
I have a question about VARCHAR fields. Our application groups here
are starting to use VARCHARs much more frequently. Even VARCHAR (2) to
(9) length fields. They say this is because some of the application
programs, specifically Java Beans cannot handle the spaces after the
value in CHAR fields.
Is anyone else seeing this trend?
I know that VARCHAR fields have 2 extra bytes of overhead. Does anyone
know if there is a significant performance impact in DML against these
fields due to tracking the length?
There is the additional storage overhead as you mention, plus this can
lead to performance issues with row overflows and/or page reorgs.
IMO, this is usually a symptom of lazy programmers rather than "the
app can''t handle extra spaces".
Is it true that in Informix VARCHAR takes more space than CHAR? In
Oracle the waste of space and CPU comes with working with CHAR and
it has been almost completely abandoned.
Thanks.
--
Daniel A. Morgan
http://www.psoug.org
da******@x.washington.edu
(replace x with u to respond)
"DA Morgan" <da******@psoug.org> wrote
Is it true that in Informix VARCHAR takes more space than CHAR?
Not at all. Just one byte extra at the beginning to record the length.
In Oracle the waste of space and CPU comes with working with CHAR and
it has been almost completely abandoned.
same is true with informix, except that upto a length of char(15) (some say even 20)
the performance gain in char is worth the space wasted. so I would always recommend
a char field upto char(15).
The difference between char and varchar becomes stark in delete-and-load tables.
That is tables which are periodically cleaned and loaded again. A table with fixed-length
columns (char, int, date etc) loads much faster than with variable length table. I think
it is something to do with the engine calculating before inserting on which page the
row will fit.
这篇关于关于VARCHAR Vs的问题CHAR字段的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
