Re: Caching queries
| From: | John Lim | 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