Hi,
I'm indexing records from different database tables and they have
identical column names in many cases. Does this mean I have to create
different indexes for each table?
TIA,
Vamsee.
Hi,
I'm indexing records from different database tables and they have
identical column names in many cases. Does this mean I have to create
different indexes for each table?
TIA,
Vamsee.
Not necessarily. If you index the table name as a separate field for
each document added to the index, it can be used (as a TermQuery
clause) to constrain searches for just documents from a specific
table. The acts_as_ferret posted to the Ferret wiki does this, for
example.
Erik
Erik H. wrote:
Not necessarily. If you index the table name as a separate field for
each document added to the index, it can be used (as a TermQuery
clause) to constrain searches for just documents from a specific
table. The acts_as_ferret posted to the Ferret wiki does this, for
example.
Thanks, Erik. That raises the obvious question I should’ve asked before
TIA,
Vamsee.
On Tue, Jan 03, 2006 at 06:05:31PM +0530, Vamsee K. wrote:
- which is a better approach and which is faster?
Imho this depends on how your queries look like.
If you want to run queries across all tables, having only one index
should be faster because no merging of results from different indexes
has to take place.
On the other hand, if you want to query only data of one of your tables,
having a dedicated index for that table should be faster.
But unless you have huge amounts of data in your indexes, in practice
the difference in speed won’t matter. At least that’s what I experienced
with Java lucene.
Jens
–
webit! Gesellschaft für neue Medien mbH www.webit.de
Dipl.-Wirtschaftsingenieur Jens Krämer [email protected]
Schnorrstraße 76 Telefon +49 351 46766 0
D-01069 Dresden Telefax +49 351 46766 66
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs