Funtick wrote: > >>then 2) get all P's by ID, including facet counts, etc. >>The problem I face with this solution is that I can have many matching P's > (10,000+), so my second query will have many (10,000+) constraints. > > SOLR can automatically provide you P's with Counts, and it will be > _unique_... > >
I assume you mean to facet by P in the C index. My next problem is to sort those P's based on some attribute of P (as opposed to alphabetically or by occurrence in C). Funtick wrote: > > Even if cardinality of P is 10,000+ SOLR is very fast now (expect few > seconds response time for initial request). You need single query with > "faceting"... > Is there a practical limit for maxBooleanClauses? The default is 1024, but I need at least 10,000. Funtick wrote: > > (!) You do not need P's ID. > > Single document will have unique ID, and fields such as P, C (with > possible > attributes). Do not think in terms of RDBMS... Lucene does all > 'normalization' behind the scenes, and SOLR will give you Ps with Cs... > If I put both P's and C's into a single index, then I agree, I don't need P's ID. If I have P and C in separate indices then I still need to maintain the logical relationship between P and C. It wasn't clear to me if you suggested I continue with either of my 2 proposed solutions. Can you clarify? Thanks, Wojtek -- View this message in context: http://www.nabble.com/Searching-and-Displaying-Different-Logical-Entities-tp25156301p25181664.html Sent from the Solr - User mailing list archive at Nabble.com.
