Andrew Sullivan wrote: > > On Sat, Mar 16, 2002 at 09:01:28AM -0500, mlw wrote: > > > "If it is mostly static data, why not just make it a static page?" > > Because a static page is a maintenance nightmare. One uses a > > database in a web site to allow content to be changed and upgraded > > dynamically and with a minimum of work. > > This seems wrong to me. Why not build an extra bit of functionality > so that when the admin makes a static-data change, the new static > data gets pushed into the static files? > > I was originally intrigued by the suggestion you made, but the more I > thought about it (and read the arguments of others) the more > convinced I became that the MySQL approach is a mistake. It's > probably worth it for their users, who seem not to care that much > about ACID anyway. But I think for a system that really wants to > play in the big leagues, the cache is a big feature that requires a > lot of development, but which is not adequately useful for most > cases. If we had infinite developer resources, it might be worth it. > In the actual case, I think it's too low a priority.
Again, I can't speak to priority, but I can name a few common application where caching would be a great benefit. The more I think about it, the more I like the idea of a 'cacheable' keyword in the select statement. My big problem with putting the cache outside of the database is that it is now incumbent on the applications programmer to write a cache. A database should manage the data, the application should handle how the data is presented. Forcing the application to implement a cache feels wrong. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
