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
