[bjourne]

Some developers love that kind of micro optimizations. Even smart ones. I've had my varchar(256) columns changed to a more modest varchar(30) because I was "wasting space." Those people dont like being wrong either so there's no point arguing it either and instead concentrate on the bigger issues.

[btilly]

I've seen that, but once the internal format is actually explained, varchar(256) generally survives.

For those who don't know, for varchar(1) through varchar(256) the internal database representation in sensible databases is one byte to say how long the varchar is, followed by the actual data. There is therefore absolutely no difference between the representation of varchar(30) and varchar(256) - it is just an arbitrary restriction on what data is allowed to fit in there. But databases that support varchar(257) need 2 bytes in front for it.

[lucaspiller]

I believe in InnoDB the way text and varchar(X) is stored is exactly the same. They both only use as much space as the data they are storing requires. However if you pass a 101 character string to a varchar(100) it will be truncated. I'd guess that is useful in some cases, but in reality you probably want to do the truncation in your application so you have more control over it.

[quesera]

Truncation is the failure mode which MySQL describes as a feature.

Don't use MySQL.

[edanm]

Thanks for the explanation, didn't know that.

Is this true in most modern DBs? (I'm thinking MySQL and Postgres particularly).

[icebraining]

Close enough in PostgreSQL. String columns larger than 256 actually use 4 bytes to indicate the length, but on the other hand, large strings are automatically compressed, so they may use less space than 4 + length.

http://www.postgresql.org/docs/9.2/static/datatype-character...

[ajanuary]

I recently discovered its a similar case for numbers in Oracle, which slightly surprised me.