Crawling a DB is not a good idea. Indexing while writing/deleting is clever. Doing it inside the DB is a solution. Java users like ORM. Compass plug Lucene indexation in the ORM's transaction. If it's wrote or deleted, Lucene is aware. Compass is opensource.
M. On Wed, 1 Oct 2008 09:12:41 -0300, "Marcelo Ochoa" <[EMAIL PROTECTED]> wrote: > Hi Zoran: > One of the biggest issues with Lucene DB integration is the network > traffic consumed as consequence of indexing or updating operation, > apart from transactionalbilty which can be relaxed in some > application. > During our Oracle Open World presentation we present some of these > issues comparing performance during indexing time (integrated solution > versus middle tier solution), network traffic, executions plans and > others. > Obviously its based on Oracle databases but the concepts are similar > for any other solutions. > You can download the complete presentation from: > http://www28.cplan.com/cbo_export/208/PS_S298820_298820_208-1_v1.pdf > http://www28.cplan.com/cbo_export/208/PS_S298820_298820_208-1_v2.pdf > To download presentations, please enter the following when prompted. > Note the Username and Password are case sensitive. > Username: cboracle > Password: oraclec6 > Or you can see on-line only the Oracle Lucene integration details > using Google docs at: > http://docs.google.com/Presentation?id=ddgw7sjp_156gf9hczxv > Best regards, Marcelo. > > On Wed, Oct 1, 2008 at 4:43 AM, agatone <[EMAIL PROTECTED]> wrote: >> >> Hi, >> I asked this question already on "lucene-general" list but also got > advised >> to ask here too. >> >> I'm working on a project that has big database in the background (some >> tables have about 1500000 rows). We decided to use Lucene for "faster" >> search. Our search works similar as all searches: you write search > string, >> get list of hits with detail link. But there is dilemma if we should > store >> more data into index than it's needed. >> >> One side of developing team insists that we should use lucene index as >> somekind of storage for data so when you get hit, you go onto details > and >> then again use lucene to find document that matches the selected ID and > take >> the data from Lucene index. So in the end you end with copying complete >> database tables into the lucene index. >> >> Other side insists on storing to index only data that is displayed > directly >> to the user when showing the search results list and needed for search >> criteria. When you go onto details, you have the matching ID so you can >> pickup that row from database by that ID rather than search it inside > Lucene >> index. >> >> Can someone please describe drawbacks and advantages of both approaches. >> Actually can someone write down what's the actual profit, where and when > of >> the Lucene itself in real production env. >> >> IT would be great if there is anyone who could write his experience with >> indexing and searching large amount of data. >> >> >> Thank you >> -- >> View this message in context: > http://www.nabble.com/Lucene-vs.-Database-tp19755932p19755932.html >> Sent from the Lucene - Java Users mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
