>Try it now:
That works now. Thanks!
>I'm curious: What are you indexing with -S prog?
A mysql database.
My company runs a jobs database (among other things) on our website. Way
back in the day, when computers and databases were slow, it was faster
to do a full-text search of a bunch of text files and pull the info out
of the files than it was to try and do regexp matching on SQL fields and
then sort out the results and access multiple tables for the information
(assuming your database even had regexp matching beyond a simple
wildcard). Swish-E came along with indexing based on properties and we
setup the jobs as text files of meta tags, essentially using Swish-E to
turn the file system into a random-access database for the jobs. This
was even easier once Swish-E allowed you to return the values of the
properties in the results. It came as close as you're likely to get to
making a file system into a real database.
The problem is that it's not relational. Several bits of data are
statically stored in the file and just updated at regular intervals.
This has worked well for several years but we're finally getting into
applications where we need immediate up-to-date links between the jobs
info and the SQL databases that comprise the rest of the website. The
search engine is built around Swish-E and I don't see any pressing
reason to change that. Swish-E is designed for this work and, IMO, you
use the best tool for the job.
With the prog method, I'll store the job listings in the SQL database
and just make a script that spits out the data to Swish-E for full-text
indexing. On searches, Swish-E will return the list of record-id's and
the results munger will do the necessary table lookups. For the tasks
that don't require "fresh" data, Swish-E can still return the data in
the "document" properties and avoid doing any table lookups at all. Best
of both worlds.
Received on Tue Aug 7 20:48:29 2001