On Thursday 04 September 2003 17:13, Bill Moseley wrote:
> On Thu, Sep 04, 2003 at 08:57:13AM -0700, William Bailey wrote:
> > > Looks more like a database select than a full-text search.
> > To be honest i didn't have much luck when searching using a database it
> > was just too slow and too much of a resource hog. On even some of the
> > more complicated searches swish-e is still very fast and fulls the
> > requirement supriseingly well. Well done all :)
> Interesting. That might change if there were a few million records.
The main problem was that the data in the database i get is not exactly in a
'nice'. Combine that with a lot of possible joins, sometimes when searching
for an artist both the recording artist and track artist need to be searched,
and then having to group the results by recording and having a generic
keyword free text search made for some quite long database queries.
This way i just query the database and build recording XML files which i then
index/search with swish. This then gives me quick search time as well as only
having to put high load the server once a week when the XML files get
regenerated and reindexed.
> > > Each AND (including the default AND operator) and OR operation is a new
> > > search. So reducing the boolean searches would be good for speed.
> > At the moment the speed is not an issue and after the first search the
> > results are cached anyway. I agree that there ar a lot of boolean
> > operations but this is a side affect of haveing a number of different
> > fields to search without any field being required.
> At the cost of a larger index, can you nest your fields:
> then search all=foo to search both at the same time?
This is true however it will not give accurate enough searches. I am already
doing this for the 'keyword' type search however.
Pro-Net Internet Services Ltd.
Received on Thu Sep 4 16:45:56 2003