Mailing List Archive


Back to the month index Back to the list index
Gary Bickford (garyb@outlawnet.com)
Tue, 7 Jan 1997 11:00:37 -0800 

Message-Id: <v01540b00aef84a157909@[208.192.38.73]>
Date: Tue, 7 Jan 1997 11:00:37 -0800
From: garyb@outlawnet.com (Gary Bickford)
Subject: Re: [mSQL] 2.0 - can it cache results?

Excellent thinking here....

Actually, for web-based applications, where some kind of CGI or PHP or
whatever is providing the interface, and taking into account that one of
mSQL's objectives is to stay small & fast, it may be useful/better to leave
it up to the interface program to drop it.

For a bookstore application I've already done, having a persistent cache
would be useful. In this application, prohbably 90% of all searches are
from a set of about 20 - the same search is done over and over, by every
user. If I had a separate db or even a set of separate tables within the
db, I could maintain a table of cached results and go there first. This is
probably true for many other applications.

I don't think it's out of line, at least in the first version, to require
the application to decide when to drop the table. Then the app could use
cookies, or any other application-dependent way, to schedule flushing.

This presumes, of course, that the SQL-ish below is the way it's done -
obviously we don't want to require this housekeeping of all apps on all
searches, just those who request it.

Then there's always cron... :)

>There's a little SQL'ism that's on the list of things to add to mSQL that
>will help you out here. It goes something like this (ignore the syntax
>as I'm not an SQL guru and I can't remember it off the top of my head).
>
> select foo, baa from table1 into table2
>
>I.e. perform your query and then store the result in a new table on the
>server. The server has to do some smarts here as ...
>
> The result table must be linked to you in some way
> It must be able to handle multiple people doing the same thin
> at the same time (i.e. this could be part of an app')
> It must be able to clean up after the session is gone so that
> you don't get hundreds of the suckers hanging around.
>
>The logical way to do this is to link the tmp table to the session handle
>in msql2d. That way it can be cleaned up at the end of the session and
>all is well. The down side is that it will not help web based app's as
>each page generates a new session :-(

end
=======
Gary Bickford, FXT Corporation http://www.fxt.com
System integration, active web site design, intranets.
garyb@fxt.com 541-923-3060

--------------------------------------------------------------------------
To remove yourself from the Mini SQL mailing list send a message containing
"unsubscribe" to "unsubscribe" to msql-list-request@bunyip.com. Send a message containing
"info msql-list" to majordomo@bunyip.com for info on monthly archives of
the list. For more help, mail owner-msql-list@bunyip.com NOT the msql-list!