Yes, it may expensive as well. But we can incorporate it in our
workflow. DVD has a new relationships with an actor - tag the actor's
key with the DVD's id as well as the DVD's ID with the actor's. May
possible lead to a kind of cascading flushing.
We have played around with integrating tagging in the application. We
were testing SQLite as a tag database. Or mySQL memory tables if you
make all keys ints. But I think it would be more elegant to have all
functionality in one product rather than craft on something different.
Zend_Cache offers tagging as a feature and Memcached as one of several
backends. I'll swing around and look how they implemented it.
Point 2 multiplies for each loosely related keys. The direct ones are
easy to hit, the others not so.
I think this makes sense, but it seems like you're shifting the
problem over to tagging. Now you have to tag James Hong with every
role he's been involved in in case the DVD availability of one of them
changes. That seems like it would be just a different expensive.
It seems like you could do the same thing just as easily in your
app at that point. e.g. if I'm invalidating a movie, I probably have
an actor list and can just asynchronously fire off concurrent
deletions to all the related actors and stuff (or better, just
asynchronously send updated information).
--Dustin Sallings
