On Tue, 2001-12-11 at 01:19, Marius Andreiana wrote:
> >
> > No, the users can save query criteria and so forth, and queries can take
> > a minute or two to run.
> so for adding/refining/substracting you use in one big query UNION,
> INTERSECT, EXCEPT instead of a temporary table?
Yes, except it is just an n-way join, where n is related to the number
of search terms they are using.
> Is it ok with your users to run a search which takes say 30 secs,
> see first 10 results, then wait again 30 secs to see the next 10 ?
> (if you run the query again...); perhaps I misunderstood something
Yes, it is. In most cases they will get a sub 5-second response anyway,
and only in rare cases do they actually want to look beyond the first
page.
> > The underlying data being queried changes a fair bit. This is a news
> > database, so the users want their queries to stay constant, but the
> > results to vary.
> yes, same here. We have members (about 13000) and staff performs
> searches with criterias like state of licensure is xx or
> number of comments > y. (The criterias expand as staff requests)
> But the data queried doesn't change as often when just browsing
> through search results, so I'd rather keep a list of IDs in a
> temporary table than run the query every time they want to see
> next page.
Well, could you tie the temp table to their session? That might make it
easier to go through and clean up the temp table later.
> Once one has these results they can go to the individual view of
> a member and change some data then return to browsing results,
> or mass-mail everybody in search results. Again, in the mass mail
> script is faster to start sending mail right away than perform
> the query (queries) again and then start with the mail.
I've never gone for that 'browse and edit results' UI concept. I just
produce a list with a bunch of URL's linking to the maintenance page
using target=_new - let them close the window when they have finished.
I sort of see where you are coming from though.
Possibly you could just store an array of ID #'s in one row of a table,
and then have one table with all of your sort results in it. If you are
paging through them then a query in a loop through entries in that array
should be very quick.
Using this approach you could also invalidate saved searches quite
easily in appropriate situations.
Regards,
Andrew.
--
--------------------------------------------------------------------
Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201 MOB: +64(21)635-694 OFFICE: +64(4)499-2267
