Re: [Phplib-users] Caching MySQL queries

[nathan r. h. <na...@ds...>]

On Fri, 26 Oct 2001, Donncha O Caoimh wrote:

> That's the simple explanation. I serialize the array and base64_encode
> it before caching it and seperate each record by a "\n". When I read it
> back I split the cache by "\n" and eval() the correct row. Not the best
> way of doing it but it's the most obvious way I thought of and the
> quickest to see if it'd work :)
>

I picked up on this late, so please shoot me if I'm straying or this has
been covered.

base64 encoding increases the size of stored vaules by a lot which could
be part of the problem when working with large result sets.  Unless you
need base64 I'd say just to just serialize the mysql result arrays, add
whatever delim you nedd and addslash() them then jsut stripslash(),
split() and eval()

Question is what kind of metadata does the cache have to make sure the
data is fresh and to determine a hit (looking back, md5 sums of the
original sql query statement.. i see that should work) and where does this
cache live?  If it's living in a db, well, then what's the point except to
speed up very complex queries.  Now if it's living in a shmem ssegment,
well, that's just darn fast..  With something like Zend cache, you may be
able to use a file and let *that* cache engine take care of it too, if you
don't feel like coding your own shmem functions

-n
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
nathan hruby / digital statement
na...@ds...
http://www.dstatement.com/

Public GPG key can be found at:
http://www.dstatement.com/nathan-gpg-key.txt
ED54 9A5E 132D BD01 9103  EEF3 E1B9 4738 EC90 801B
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-