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.
