This article explains in-depth why calculating facets is not practical in pure SQL: http://www.kimbly.com/blog/000239.html
Cheers, Mauricio On Wed, Sep 2, 2009 at 5:30 AM, gwk <g...@eyefi.nl> wrote: > Fuad Efendi wrote: > >> "No results found for 'surface area 377', displaying all properties." >> - why do we need SOLR then... >> >> >> >> >> > Hi Fuad, > > The search box is only used for geographical search, i.e. > country/region/city searches. The watermark on the homepage indicates this > but the "search again" box on the search results page does not, I'll see if > we can fix that. > > We use Solr not so much for the searchbox, which to be honest was an > afterthought. But we do use Solr for faceting. Honestly, the thought of > writing an SQL query which calculates all these facet counts every time a > search parameter is changes gives me a headache, I don't think it's possible > to do it in one query (although maybe, but I don't think anybody would want > to maintain it). As for performance, every nontrivial database/search engine > is affected by dataset for all but the simplest queries, and in my tests > Solr trumps Mysql by a huge margin for our use case. We use a database to > store our data in a somewhat normalized way, which is good for data > consistency, but not so good for retrieval speeds. This is what makes Solr > so useful for us, we can index all data in denormalized form with all data > for a property in one record. While the (sql) database remains authoritative > > Full-text search is only one part of Solr, while an important part it isn't > the only reason for using Solr. In our case, since we provide support for > multiple language we try not to store textual descriptions but every facet a > property can have. This gives us exactly the data needed to perform faceting > but not so much on the full text search (which is used mind you, to find > suggestions when you use the search box). > > Regards, > > gwk >
