Re: Caching queries

From: Date: Sun, 02 Dec 2001 15:53:10 +0000
Subject: Re: Caching queries
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-3299@lists.php.net to get a copy of this message
Tomas V.V.Cox <cox@idecnet.com> wrote in message news:3C0A39F4.9F0C98D5@idecnet.com... > Peter Bowyer wrote: > > > > At 05:53 AM 12/2/01 +0100, Tomas V.V.Cox wrote: > > > >* (4.13) Results cache to be done by the PEAR_Cache class > > > > Could we have a generic cache class interface? For instance, Manuel has > > written one, and I have been reliably informed that it is more > > full-featured than the current PEAR class, and would therefore be better on > > a high-load website. Have a look at PHPClasses for it if you're > > interested. > > No problem of course. I'm not experienced with Cache systems and its > speed benefits applied to databases and my opinion here is not relevant. > Perhaps John could raise his voice over this topic too. > > > Tomas V.V.Cox Hi Tomas, Like your proposed work. I might also propose that the portability class be implemented like this as I have tested this with oci8 and it appears to work quite well: DB_Common --> DB_Connection_Fast --> DB_Connection_Portable The SQL parser is a nice idea, but I would definitely place it in the portable camp. Parsing different SQL dialects is very tricky and you know I only like simple hacks :) Here are some additional suggestions: Disconnected Recordsets ======================= I would also like recordsets to support disconnection and be transportable. This will make the design flexible enough for the next generation of the Internet (web services). In other words, $rs = $conn->query('select * from table'); XML_RPC_Send( // or SOAP_Send $destination = "webservice.somewhere.com", $serialformat = $rs->serialize('xml'), $queryError = DB_OK); and the "webservice.somewhere.com" would be able to process the recordset. This can be implemented if we have a recordset class which uses a 2-dimensional array internally, and can be serialized into either XML or PHP serialize format. In ADODB, the array recordset class is also used for recordset caching. And since cached recordsets are serialized objects stored in files, it unifies everything. ADODB array recordsets also (optionally) contain the INSERT_ID and AFFECTED_ROWS for DML statements which do not retrieve any rows. Hmm, perhaps I should call this result sets, as an INSERT will definitely not return a record, but a result... This system is so effective that I have used it to as a database bridge so that Linux boxes can query Windows databases transparently (eg. FoxPro and MS Access). This array recordset interface is also useful if you have any type of data record. It could be XML, or CSV data, etc. eg. DB_Recordset --> DB_Recordset_Array -->DB_Recordset_XML -->DB_Recordset_CSV The array recordset is also useful for limitQuery operations, as you can suck all the data into the array recordset. Microsoft's ADO+ has additional features, like being able to send an entire database as an XML file, processing the XML locally, then sending the results back to the original database for processing. ADO+ can also capture table relationships (1-1, 1-many). This i think is too slow to do in PHP (practical in C though) currently, but I will be happy to be proven wrong. Is Recordset Caching Useful? ============================ You also asked about caching: Two levels of caching are common: HTML and Record Sets. HTML caching is best when the HTML does does not depend on the session (eg. userid, group permissions), but is global. Record set caching is best when the HTML generated depends on session settings, so HTML cannot be easily pregenerated. So there are some cases when caching record sets are the way to go, and when HTML caching is superior. Regards, John

« previous php.pear.dev (#3299) next »