Re: Help with design choice: join or multiValued field
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 <f...@efendi.ca> wrote: > Correct: multivalued field with 1 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.kil...@gmail.com> <karl.kil...@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 1 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 1 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
Correct: multivalued field with 1 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.kil...@gmail.com> <karl.kil...@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 1 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 1 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?
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 1 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 1 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?