Back to the month index |
Back to the list index
|
David J. Hughes (bambi@Hughes.com.au)
Tue, 7 Jan 1997 21:27:09 +1000 (EST)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: David J. Hughes: "Re: [mSQL] mSQL 2.0 Beta 2"
- Previous message: David J. Hughes: "Re: [mSQL] ORDER BY + _rowid == bug?"
- In reply to: Alex Tang: "Re: [mSQL] ORDER BY + _rowid == bug?"
- Next in thread: rasmus@mail1.bellglobal.com: "Re: [mSQL] 2.0 - can it cache results?"
- Reply: rasmus@mail1.bellglobal.com: "Re: [mSQL] 2.0 - can it cache results?"
Date: Tue, 7 Jan 1997 21:27:09 +1000 (EST) From: "David J. Hughes" <bambi@Hughes.com.au> Subject: Re: [mSQL] 2.0 - can it cache results? Message-Id: <Pine.SUN.3.91.970107212248.2365J-100000@webster.AusWeb.com.au>
On Sat, 4 Jan 1997, Gary Bickford wrote:
> Creeping feature creature - Gee, folks, this would be really handy - I
> didn't see anything in the docs on 2.0, so I'll bring it up here.
Great place to bring it up!
> There's lotsa times where I'd like to do one search, build a temporary
> table and re-search it, possibly saving a lot of search time (though with
> many of the new features of 2.0, I'd probably have less need). I'm
> thinking that the temp files (created by msql 1.0, at least) might be just
> what I need, only inaccessible at this time.
Yup. 2.0 will help here with the performance increase but it's still a
valid point.
> Of course, I could do this manually (I use PHP), receiving the data and
> then creating a table and passing the data back, but as many have said
> including Bambi, passing the data through the connection is often the
> slowest part of the process.
Certainly can be.
> But perhaps this is taking msql into the realm of big, unwieldy, ... dbms,
> which is not a good thing.
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 :-(
Something to think about though.
Bambi
...
--------------------------------------------------------------------------
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!
- Next message: David J. Hughes: "Re: [mSQL] mSQL 2.0 Beta 2"
- Previous message: David J. Hughes: "Re: [mSQL] ORDER BY + _rowid == bug?"
- In reply to: Alex Tang: "Re: [mSQL] ORDER BY + _rowid == bug?"
- Next in thread: rasmus@mail1.bellglobal.com: "Re: [mSQL] 2.0 - can it cache results?"
- Reply: rasmus@mail1.bellglobal.com: "Re: [mSQL] 2.0 - can it cache results?"