lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Kildén <karl.kil...@gmail.com>
Subject Re: Help with design choice: join or multiValued field
Date Tue, 14 Feb 2017 08:59:01 GMT
Thanks for the reply! We did it this way and it's seems to turn out really
well

On 6 February 2017 at 22:57, Fuad Efendi <fuad@efendi.ca> wrote:

> Correct: multivalued field with 10000 shop IDs. Use case: shopping network
> in U.S. for example for a big brand such as Walmart, when user implicitly
> provides IP address or explicitly Postal Code, so that we can find items in
> his/her neighbourhood.
>
>
> You basically provide “join” information via this 10,000-sized collection
> of IDs per document. It almost doesn’t have any impact on index size. User
> query needs to provide list of preferred IDs (if for example we know user’s
> geo location). And for this “Walmart” use case you may also need “Available
> Online Only” option, etc.
>
>
> From: Karl Kildén <karl.kilden@gmail.com> <karl.kilden@gmail.com>
> Reply: solr-user@lucene.apache.org <solr-user@lucene.apache.org>
> <solr-user@lucene.apache.org>
> Date: February 6, 2017 at 5:57:41 AM
> To: solr-user@lucene.apache.org <solr-user@lucene.apache.org>
> <solr-user@lucene.apache.org>
> Subject:  Help with design choice: join or multiValued field
>
> Hello!
>
> I have Items and I have Shops. This is a e-commerce system with items from
> thousands of shops all though the inventory is often similar between shops.
> Some users can shop from any shop and some only from their default one.
>
>
> One item can exist in about 10000 shops.
>
>
> - When a user logs in they may have a shop pre selected so when they
> search for items we need to get all matching documents but if it's' found
> in their pre selected shop we should mark it out in the UI.
> - They need to be able to filter out only items in their current shop
> - Items found in their shop should always be boosted heavily
>
>
>
> TLDR:
>
> Either we just have a multiValued field on the item document with all
> shops. This would be a multivalued field with 10000 rows
>
> Or
>
> Could we have a new document ShopItem that has the shopId and the itemId
> (think join table). Then we join this document instead... But we still need
> to get the Item document back, and we need bq boosting on item?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message