A SQL database is sometimes overkill if the amount of data to be stored is relatively small, or if the data is only written/read once (or at most a few times). But if you start having more than trivial amounts of data that you may need to access in different ways from multiple programs (or from multiple copies of the same program) then the SQL database gives you flexibility and speed, and you don't have to reinvent that particular wheel.

To get back to your particular example, I've implemented discussion boards (in perl) using three different back-ends. The first used NNTP and used inn as the "database" to store the discussion. The second used DB_File (one file per "discussion"), and the third used a SQL database to store the message meta-data (though not the message text - that was stored separately in the file system).

All in all the third technique gives you the most power, and the most flexibility, and automatically handles things like concurrency, update locking, etc.

If I had to do it again I'd definitely store this sort of data in a SQL database, unless it was shown that this solution wouldn't provide sufficient performance (though I'm not sure what other solution might provide better performance.)

Michael