Re: How to manage search results?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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



[Index of Archives]     [Postgresql General]     [Postgresql Admin]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Yosemite Backpacking]     [Postgresql Jobs]

  Powered by Linux