There is often a tradeoff in dynamically allocated data structures between how little memory you use, and how fast your data access and manipulation can be. DB_File has unused memory sections. But that doesn't matter for access because you don't sequentially scan through the file, you jump right to the data, and it is a good thing for writing because if you want to add a little bit to one record, you don't have to rewrite the whole file to get the space.

But that doesn't matter for access because you don't sequentially scan through the file, you jump right to the data, ...

If the file page you're jumping to is already in the kernel's disk cache, this is a win. But if getting to the target page requires moving the disk head, you might be better off with a sequential scan. For an infrequently accessed file in the 7-8 disk page range, I suspect that the linear scan might win.

I think we're in the toss-up category.

BTW, this is a tricky one to test by profiling, since you may have to go out of your way to make sure that the file isn't cached.

Thank you.

I agree with dws that reading small flat file with file caching can be faster, but I believe we need to ask business questions: if small number of users, speed gain will not be important enough for not applying scalable solution, so why not to do it properly? Next time, when cynix will need accomodate more users, s/he can start with something better than flat files...

Just my $0.02

pmas
To make errors is human. But to make million errors per second, you need a computer.

It may not be possible to do this, but if you do it'll be faster than both the methods you mention.

____________________
Jeremy
I didn't believe in evil until I dated it.