PHP has some implications for using long text in an associative array?

I am making a database class in PHP and I want to make a query result cache in an associative array. My idea is to use sql element as index of cache array, might this be a good idea? or should I use md5 from sql?

class DB{
const HOST = 'localhost'; //Your Database Host!
const USER = 'user'; //Your Database Username!
const PASSWORD = 'pass'; //Your Database Password!
const DATABASE = 'database'; //Your Database Name!

private static $Instance;
private static $cache = array();

private function __construct(){
    self::$Instance = mysql_connect(self::HOST, self::USER, self::PASSWORD) or die("Could not connect to database server<br/><b>Error:</b>".mysql_error());
    mysql_select_db(self::DATABASE) or die("Could not connect to database<br/><b>Error:</b>".mysql_error());
    return self::$Instance;
}

public static function DB(){
    if(!isset(self::$Instance)){
      $c = __CLASS__; 
      new $c(); 
    }
    return self::$Instance;
}

public static function QueryUnique($query){
    $query = "$query LIMIT 1";
    //$h = md5($query);
    $h = $query;
    if(isset(self::$cache[$h]))return self::$cache[$h];

    $result = mysql_query($query, self::DB());
    self::$cache[$h] = mysql_fetch_array($result);
    return self::$cache[$h];
}

      

}

good day

+2


source to share


5 answers


Before going too far through your implementation, you should know that mysql does its own query caching , and it has several important advantages over your implementation:



  • The cache is shared across all PHP requests.
  • Cached results are automatically cleared when the table data changes.
  • The cache is limited to a specific memory size (rarely used queries will be excluded from the cache)
+3


source


mysql data caching can be a little risky, it makes a lot of assumptions about things, however, saying that the md5 checksum of the sql row is a good way to generate an id for your cache data, however you will need to normalize the sql first, for example:

'select 1+2'
'select 1 + 2'
' select 1 +2'

      



each will give a different checksum, you will need to make sure any small differences between the same query are taken care of.

+1


source


There shouldn't be much impact other than a little extra memory usage, but compared to the query result, I don't think that would be a problem.

Associative arrays are ordered maps, so finding the correct index shouldn't be very dependent on the total length of the string. The only downside was that most of the lines start with the same text.

I would not rely on MD5 hash alone for your queries. It is possible (if unlikely) that a hash collision will occur and it will choose a completely different query result. However, this can be an acceptable risk to your application.

Personally, I would not do this at the query level at all. The cacheability usually depends on the type of data returned. If you cache at this level, your application will be completely agnostic about what it caches.

+1


source


The hash (md5, sha1) will consume less memory space.

0


source


If the request is quite long, I would use a hashcode (like md5):

  • it will probably use a little less memory (not that important I suppose)
  • it will allow you to store this in some other cache like a file or APC or memcached or whatever, without changing the index.

Given the low risk of collisions with md5, it doesn't seem "dangerous" for this.

The only problem I see is it might be harder to find your cached data when debugging, whether with var_dump

or any "real" debugger :-(

0


source







All Articles