> Just execute 20 SQL queries with filters
> Same with SOLR vs. Lucene, standard Lucene queries "filter1:value1 AND
> facet2:value2" ... "filter1:value1 AND facet2:value99" are functionally
the
> same as SOLR faceting (99 docset intersections in RAM) and (sooner or
later)
> implementation
> This article explains in-depth why calculating facets is not practical in
> pure SQL: http://www.kimbly.com/blog/000239.html
-> "The problem is that SQL isn't really capable of expressing set
intersections."
But this article is not applicable to described use case: we are
_faceting_on_filtered_
Hi gwk,
Thanks for reply!
Yes, SOLR gives out-of-the-box
- indexes
- implicit data normalization
- fault-tolerance, replication, scalability
- performance
(so that we can save _huge_ money & time)
But from just an engineering viewpoint, forgetting cost&time, SELECT
COUNT(*) ... WHERE ... seems
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 wrote:
> Fuad Efendi wrote:
>
>> "No results found for 'surface area 377', displaying all properties."
>> - why do we n
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
"No results found for 'surface area 377', displaying all properties."
- why do we need SOLR then...
