lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: Index design question
Date Sat, 06 Aug 2005 16:30:31 GMT

> Let me describe my issue taking a simpler model. Lets say I were to
> build a 
> blog which allows each post to have multiple keywords. I want to
> provide a 
> search over the posts but restricted to a subset of the keywords (say
> - 
> python, windows, etc.). How can I structure the index in this case. I
> had 
> though of 2 fields, one a list of keyword ids and the other for post 
> contents. (The reason why I go for keyword ids is because the keyword
> is a 
> foreign key whose string could be changed independent of the post).
> What do you think?

If you store only IDs in Lucene, you won't be able to search using
keywords (text).

> Also, from a design orientation for the use case I described above,
> would it 
> be better to go for something like tsearch2 (I use postgres) in this
> case 
> because keyword searching is just one way of searching in my app. The
> data 
> could be searched across many other fields which are being done by
> sql's. 
> Does it really help in using something like lucene because I am
> worried 
> about the burden of maintaing the 2 data repositories (db and lucene
> index) 
> in sync. I am asking this because if I go for tsearch2 the data is in
> only 1 
> place and also updates, deletes to the data are handled for free by
> the db 
> for me.
> Does anybody have any suggestion?

It's up to you to pick the route.  Going to PG-only route probably
means less powerful searching.  Going PG+Lucene route means you have to
maintain PG and Lucene data in sync.  In my experience, doing the
latter is not very hard.  Another option to consider is talking to PG
people and exposing them to Lucene4c, which they may want to embed in
PostgreSQL.  That way you get PG+Lucene in a single package.


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- -- Find it. Tag it. Share it.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message