What about usgin dynamic fields to get this job done? Of course, it would turn your queries a little sharper.
2008/5/27 sunil sarje <[EMAIL PROTECTED]>: > > Hi Alan, > > This is very common problem that every app would face while enabling the > application search using any kind of search engine technology. > > I would create 2 indexes > 1. city with all city related information for crime rate, school districts, > proximity to sports, etc +city code > 2. real estate listing documents + city code for each listing > > With this you dont have to change the real estate index when city related > info is changed. > > For search you need to do 2 searches for single search request. > > Implement either custome filter (extend SolrDistpatchFilter) or custome > response writer. > a. Search for city and bring all cities for the given city-related > criteria. > b. Search listing with city codes from a. search result. (max cities - 1024 > default max count in criteria) > > OR > > If you want to use out of the box solr feature then make multiple ajax > calls > from user interface. > > > hope this helps. > -sunil > > > > alan. wrote: > > > > Hi all, > > > > What is the best way to represent a 1-N relation > > between two tables in a DB as a Solr document? > > > > I'm trying to figure out the best way to represent objects in > > my domain as Solr documents. As a representative example, > > I'll use the domain of real estate where there are cities > > and each city has multiple listings (1-N relation) > > > > Let's say I'm searching for homes but the first thing I want to do is > > identify the best city to live in. A good city could be defined > > by crime rate, school districts, proximity to sports, etc. > > > > As part of identifying the best city, I would like to exclude > > cities that don't have listings in the price/size that I'm looking for. > > > > One approach is to create a 'listing' document that has > > denormalized 'city' information. We could search for > > listings, use a 'city' facet to identify candidate cities, > > and then order the 'city' facets. (For lack of a better > > term, I'm calling this a denormalized representation) > > > > Another approach is to create a 'city' document that has > > 'listing' information attached as multiple-values or encoded > > into a field. We could search for cities, and > > filter out cities that don't meet price/size requirements. > > (Once again, for lack of a better term, I'm calling this an > > aggregated representation) > > > > So to restate my question a little differently, what are > > the advantages of using a denormalized vs an aggregated > > representation? Are there other approaches? > > > > Thanks > > > > Alan > > > > > > > > -- > View this message in context: > http://www.nabble.com/Best-way-to-represent-a-1-N-relation--tp17475861p17493360.html > Sent from the Solr - User mailing list archive at Nabble.com. > > -- Alexander Ramos Jardim
