>>57
Plus the web-side component of an application like that can typically be scaled with far less pain than the big ol' xbox-hueg centralized database. It's just more hardware and that's that, whereas scaling a database means more I/O bandwidth and more CPU sockets.

So it makes sense to stick as much of the required processing in the website layer, as long as this doesn't mean doing SQL joins in the application or other database abuse. Caching, too, is usually best done at the web server assuming that coherency is being taken care of.

All of this is obviously immaterial to stuff that just runs on a web hosting account. Hell, I remember the etherchan wiki (RIP) dying because mediawiki, or that particular mediawiki installation anyway, banged the shared database server too hard. ... though I've got a suspicion that the database administrators had calmly dropped some of the indexes that mediawiki required for proper performance, thus provoking unholy quantities of sequential scans.

Also, holy shit are you people polite. Four entirely bumpworthy replies and all of them are saging...