You could just make a separate Lucene index with the document ID unique and with multiple tag values. Your schema would have the entryID as the unique field and multiple tag values per entryID.
I just made a phrase-suggesting clone of the Spellchecker class that is almost exactly the same. It indexes multiple second words for each single first word. It was my first Lucene project and was very easy to code. Lance On 10/9/07, Pieter Berkel <[EMAIL PROTECTED]> wrote: > > Given that the tables are of type InnoDB, I think it's safe to assume that > you're not planning to use MySQL full-text search (only supported on > MyISAM > tables). If you are not concerned about transactional integrity provided > by > InnoDB, perhaps you could try using MyISAM tables (although most people > report speed improvements for insert operations (on relatively small data > sets) rather than selects). > > Without seeing the actual queries that are slow, it's difficult to > determine > what the problem is. Have you tried using EXPLAIN ( > http://dev.mysql.com/doc/refman/5.0/en/explain.html) to check if your > query > is using the table indexes effectively? > > Pieter > > > > On 10/10/2007, Lance Norskog <[EMAIL PROTECTED]> wrote: > > > > You did not give your queries. I assume that you are searching against > the > > 'entryID' and updating the tag list. > > > > MySQL has a "fulltext" index. I assume this is a KWIC index but do not > > know. > > A "fulltext" index on "entryID" should be very very fast since > > single-record > > results are what Lucene does best. > > > > Lance > > >
