The chances of an md5 collision are pretty low. Even lower if you go
with a sha1 hash instead of md5.
Ah, if only that were true. In 3 years, I saw 10 collisions with
session ids and cache keys. Nasty stuff when it happens. We quite
using md5() alone for anything "unique".
The good news for Paras is that if he uses pecl/memcache, they deal with
the disallowed character issue for you. Nice feature of that client.
So, you only have to ensure your key is less than 250 chars. In our
code we do (did actually, we quit using SQL cache) something like this:
if(strlen($sql) > 250){
$key = md5($sql)."_".sha1($sql);
} else {
$key = $sql;
}
md5 is slow, sha1 is slow, blah blah blah. No, they aren't. Not
relatively anyway. Because the two use different algorithms, the
likely hood of getting an md5 and sha1 collision on the same string are
astronomical.
Of course, it is much better to cache definable objects. Have a read of
a paper I wrote in 2001 on the subject. It is not about memcached, but
the same concepts apply to any cache in terms of what to cache, how to
cache and when to cache.
http://dealnews.com/developers/caching-2001.html
Read this too: http://brian.moonspot.net/2007/06/23/caching-and-patience/
Brian.
