Sorry, I was not being exact with "store". Lucene has separate control over whether the value of a field is stored and whether it is indexed. The term "nurse" might be searchable, but the only value that is stored in the index for retrieval is the database key for each matching job.
It seems like text search should be easy to add to a transactional database, but lots of smart people have tried to make that work and failed. Maybe it is possible, but neither Oracle nor Microsoft nor the open source community have been able to make it happen. The text search in RDBMSs seems to always be slow and lame. There is one product that does transactional query and text search: MarkLogic. It does a good job of both, but it is very XML-centric. It might be a good match, if you are into commercial software. It is a rather different style of programming than SQL or Lucene. You write XQuery to define the result XML with the contents fetched from the database. wunder (not affiliated with MarkLogic) On 9/22/06 12:42 PM, "Tim Archambault" <[EMAIL PROTECTED]> wrote: > I'm really confused. I don't mean "store" the data figuratively as in a > lucene/solr command. Storing an ID number in a solr index isn't going to > help a user find "nurse". I think part of this is that some people feel that > databases like MSSQL, MYSQL should be able to provide quality search > experience, but they just flat out don't. It's a separate utility. > > Thanks Walter. > > On 9/22/06, Walter Underwood <[EMAIL PROTECTED]> wrote: >> >> On 9/22/06 12:25 PM, "Tim Archambault" <[EMAIL PROTECTED]> >> wrote: >> >>> A recruitment (jobs) customer goes onto our website and posts an online >> job >>> posting to our newspaper website. Upon insert into the database, I need >> to >>> generate an xml file to be sent to SOLR to ADD as a record to the >> search >>> engine. Same goes for an edit, my database updates the record and then >> I >>> have to send an ADD statement to Solr again to commit my change. 2x the >>> work. >>> >>> I've been talking with other papers about Solr and I think what bothers >> many >>> is that there a is a deposit of information in a structured database >> here >>> [named A], then we have another set of basically the same data over here >>> [named B] and they don't understand why they have to manage to different >>> sets of data [A & B] that are virtually the same thing. >> >> The work isn't duplicated. Two servers are building two kinds of index, >> a transactional record index and a text index. That is two kinds of >> work, not a duplication. >> >> Storing the data is the small part of a database or a search engine. >> The indexes are the real benefit. >> >> In fact, the data does not have to be stored in Solr. You can return a >> database key as the only field, then get the details from the database. >> That is how our current search works -- the search result is a list >> of keys in relevance order. Period. >> >> wunder >> -- >> Walter Underwood >> Search Guru, Netflix >> >>
