Re: char vs. varchar

In article <38EB425C.7BFB9E33@yahoo.com>, Red Valsen <red_valsen@yahoo.com> wrote: > My Java developers have been struggling mightily against character type > columns. They have been carping about the need to trim, in one way or > another, trailing blanks from all manner of values they pull from > tables. Why can't all those nasty fixed length columns be > varchar(255)? Arguments of higher overhead and storage requirements > didn't satisfy. > > Why shouldn't all those chars be varchars? And exactly what are the > higher overhead and storage requirements? > Higher storage requirements: each varchar column takes up the length of the stored string + 2 bytes. If you know you will usually be taking up all of the available space (storing a string of length 20 in a VARCHAR(20) column) you will be taking up the whole column plus 2 bytes per record. Higher overhead: When informix reads the row it first has to read a hidden field in the row that tells it how long the string is going to be. Then it reads that many bytes from the actual column. This adds an extra step to each and every row read. If you aren't going to be saving space, I wouldn't use them because of the performance degredation. One thing they might try is in their code, in the SQL statement, (if they're using straight select statements and not stored procedures, which is a bad thing, but on a different topic) call something like 'select trim(field1) from tab1...'. Another option (and I'm not sure this will work, my engine doesn't support varchars so I can't test it) is to use stored procedures returning type VARCHAR and select a regular char into it and trim it. Like I said, I don't know if it will produce the result you expect, but it's worth a try. -- # unrm / ksh: unrm: not found # man cpio Sent via Deja.com http://www.deja.com/ Before you buy.