handling multiple db calls on member pages

[musicales]

I'd like to hear how people deal with 'myspace'-style pages where one single page has a list of comments, a list of forum posts, a list of mp3s etc. Each one requires a separate database call.

Is there any way round this any knows of? My current method which is quite cumbersome is to store a static file for each of the sections which is included in the page. So each time a member makes a new post their static file gets updated. But it means the server has thousands and thousands of little files which feels a bit 'old-fashioned'. Are there any alternatives?

[physics]

One thing is that instead of caching the 'things' in files you can cache them in the db... in a cache table. This should be faster than using flat files unless your coding for interfacing with the flat files is really excellent and you have a file system that can handle tons of little files in a dir quickly.

[physics]

Another option is to let the database do the caching for you and save yourself a lot of trouble:
[dev.mysql.com...]

[fischermx]

It is not old-fasioned. I've worked on DB all my life, but I'm not sold with the idea that a website should store and use exclusively a database management system without intermmediate files.
You'll be surprised to know how some very big sites don't use a database to store the data, but plain files. Blogger is an example.
Other uses approaches like yours, flushing data from the database to static files txt, html or xml files that are read instead of going to the database.
Check these:
[radar.oreilly.com...]
[radar.oreilly.com...]
[radar.oreilly.com...]
[radar.oreilly.com...]