Hi Eric,

What you describe is very close to what I've done with my Postgres
solution to search some EAD docs using a Perl/CGI.  The XML starts on
the filesystem.  I then index it with swish-e and insert the XML blob
into Postgres since swish-e isn't entirely XML aware.  In case I need
extra ability to deliver XML text fragments to enrichen the output of my
HTML in the CGI,  I use the Postgres/Throwingbeans XPath functionality
with a simple select SQL.  The database really does very little in my
app (it's only one table, actually) -- it's swish-e that drives it, and
it's really fast.

Clay

Eric Lease Morgan wrote:

> Yep, this is my thought as well. My plan will be to write easily
> indexable content to the file system and/or create a dump from my
> database, and then feed this output to an indexer. My current favorite
> is swish-e. Swish-e will provide all the searching functionality I
> could desire. Results returned from swish-e will be either URL's
> pointing to documents on the file system or to keys in the the
> database. Documents on the filesystem would most likely highly
> structured HTML documents. If keys are returned, then I would use the
> key to extract the necessary information from the database, build some
> sort of document on the fly, and return the results to the browser.
>
> I like this sort of approach instead of querying the database directly
> because querying the database directly forces me to create all sorts of
> ugly SQL statements defining specific fields to query. Ick, again.
>
> --
> Eric Morgan