On Sun, 24 Apr 2016 14:09:50 +0100 Simon Slavin <slavins at bigfraud.org> wrote:
> > On 24 Apr 2016, at 1:51pm, Carlos <milon at terra.com.br> wrote: > > > But, with very fast CPUs and RAM memory buffers for the directory > > entries in the disks, the variable length records would probably > > result in gain for much less I/O for the data. > > Agreed. Which is one reason why fixed-length string columns are less > important and less used now. When the bottleneck is the speed of the > backing store, storing fewer characters can mean the difference > between having to write one sector or two. You still have only two choices: compute or seek. The physical structure is either like an array, and you can compute the record's location, or it's like a list, and you have to iterate. > Another reason is that we use Unicode not ASCII/SIXBIT/EBCDIC, and in > Unicode different characters take different numbers of bytes. So > even if you're storing a fixed number of bytes the convenience of > always knowing exactly how many characters to display no longer > exists. These are different concerns, and they don't really pose any difficulty. Given an encoding, a column of N characters can take up to x * N bytes. Back in the day, "x" was 1. Now it's something else. No big deal. Note that SQL still defines lengths in terms of characters. It's up the DBMS how to store them (regardless of the agreed-on encoding). --jkl
