<div><div>This is why putting memcache in the database layer is a bad idea. You have to parse SQL to do it correctly. However, if you cache data at the application level it's easier to know what you're caching (and what needs to be dirtied). And you are able to cache the data after it's been massaged for presentation so you save yourself that work too when retrieving the cached data the next time.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Message: 2<br>Date: Fri, 4 Nov 2005 12:38:49 -0800<br>From: mike <<a href="mailto:mike503@gmail.com">
mike503@gmail.com</a>><br>Subject: Strategies to cache from MySQL (or any DB I suppose)<br>To: <a href="mailto:memcached@lists.danga.com">memcached@lists.danga.com</a><br>Message-ID:<br> <<a href="mailto:bd9320b30511041238j54b31cb2keaffb59d9ad798a2@mail.gmail.com">
bd9320b30511041238j54b31cb2keaffb59d9ad798a2@mail.gmail.com</a>><br>Content-Type: text/plain; charset=ISO-8859-1<br><br>Obviously it's quite easy to request a single row from a table based<br>on a key of "table:PK" - however, what if I do not query the table
<br>based on it's PK?<br><br>I'd say the majority of the time, my highest traffic queries are not<br>using a PK (or a compound PK) but a combination of [indexed] columns.<br>Perhaps this is where I become "re-educated" in my thinking, and you
<br>guys say "hey stupid, instead of sending one database query to your<br>database, break it up into two" - I *may* be over-engineering this.<br><br>Take for example my forum code.<br><br>User requests /forum/posts.php?t=$threadid
<br><br>I select from my database:<br>SELECT foo,bar,baz FROM posts WHERE threadid=$threadid<br><br>Obviously, when checking to see if the cache exists for that, I<br>suppose I could use "posts:$threadid" for the key. But then I have to
<br>make sure that any time I may modify a row returned from that query, I<br>have to dirty the cache for any already-cached information with<br>threadid of $threadid.<br><br>Hopefully I'm making sense. Perhaps someone else has some BKMs on how
<br>to change/break up database operations so that I can do caching on<br>nearly every type of SELECT I will use. Because I'd like to leverage<br>memcache for everything possible.<br><br>File caching is easy - the key would always be the filename (or some
<br>sort of token based on it) - but the database stuff gets interesting<br>based on how the data is being retrieved, and also how it's updated.<br><br>Thanks in advance,<br>mike<br><br><br>------------------------------<br>
<br>_______________________________________________<br>memcached mailing list<br><a href="mailto:memcached@lists.danga.com">memcached@lists.danga.com</a><br><a href="http://lists.danga.com/mailman/listinfo/memcached">http://lists.danga.com/mailman/listinfo/memcached
</a><br><br><br>End of memcached Digest, Vol 16, Issue 5<br>****************************************<br></blockquote></div><br>