You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Karl Kildén <ka...@gmail.com> on 2017/02/06 10:57:34 UTC
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?
Re: Help with design choice: join or multiValued field
Posted by Karl Kildén <ka...@gmail.com>.
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 <fu...@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 <ka...@gmail.com> <ka...@gmail.com>
> Reply: solr-user@lucene.apache.org <so...@lucene.apache.org>
> <so...@lucene.apache.org>
> Date: February 6, 2017 at 5:57:41 AM
> To: solr-user@lucene.apache.org <so...@lucene.apache.org>
> <so...@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?
>
Re: Help with design choice: join or multiValued field
Posted by Fuad Efendi <fu...@efendi.ca>.
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 <ka...@gmail.com> <ka...@gmail.com>
Reply: solr-user@lucene.apache.org <so...@lucene.apache.org>
<so...@lucene.apache.org>
Date: February 6, 2017 at 5:57:41 AM
To: solr-user@lucene.apache.org <so...@lucene.apache.org>
<so...@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?