: Yep, my advice always is use a db for what a db is designed for (set : manipulation) and use Lucene for what it is good for, but some people
careful how you word that advice ... Solr's first use case was faceted browsing because using Lucene to generate BitSets and computing the intersection counts proved to be so much faster then the corrisponding set operations in MySQL ... I'm sure there are some queries just can't be done as efficinelty in Lucene as in a DB and many more where they can only be done efficinelty if you optimize for them in your document structure (ie: find all docs where hte last edit date is less then 30 days before the publish date; or find all people who have authored more then 10 documents) but i suspect that for just about any query you can think of ... if you know what the query structure is oging to be in advance, and you really want to optimize for it, there are probably more efficinet ways to "index" your data then a strictly relational database to make those queries fast ... and a Lucene index might work just as well as something hand rolled. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
