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 Adeel Qureshi <ad...@gmail.com> on 2011/08/28 23:52:18 UTC
schema design question
Hi there
I have a question regarding how to setup schema for some data. This data is
basically parent-child data for different types of records .. so
a bunch of records representing projects and subprojects where each
subproject has a parent project .. and a project has many child sub projects
another bunch of records reprensenting data for projects and linked projects
.. same parent child relationship here
another bunch representing project and linked people ..
so there are two ways I was thinking this kind of data can be indexed
1. create a single store called lets say CollectionData. use dynamic fields
to post all this different data but use a type field to identify the type of
records . e.g. to post two docs one representing project->linkedproject and
another project->linkedpeople info
<doc>
<id>123</id>
<type>LinkedProjects</type>
<childName_s>child project name</childName_s>
<childStatus_s>child project status</childStatus_s>
...
<parent_s>parent info</parent_s>
...
</doc>
<doc>
<id>123</id>
<type>LinkedPeople</type>
<childName_s>child person name</childName_s>
...
<parent_s>parent info</parent_s>
...
</doc>
now from the same store I can run queries to get the different data while
restricting the resultset on one type of records using the fq param ..
2. approach would be to create multiple stores for each different type of
records .. with pretty much the same schema but now we dont need the type
field because linkedProjects are in a linkedProjects store and linkedPeople
are in linkedPeople store .. only drawback i guess is that you could have a
few stores
my question to you guys is which approach makes more sense. I would
appreciate any comments.
Thanks
Adeel
Re: schema design question
Posted by Erick Erickson <er...@gmail.com>.
I admit I just glanced at your problem statement, but
three things come to mind...
1> have you looked at the "limited join" patch and would
that work?
2> try searching the list for "hierarchical", very similar
questions have been discussed before, although I
don't quite remember the answers....
Best
Erick
On Sun, Aug 28, 2011 at 5:52 PM, Adeel Qureshi <ad...@gmail.com> wrote:
> Hi there
>
> I have a question regarding how to setup schema for some data. This data is
> basically parent-child data for different types of records .. so
>
> a bunch of records representing projects and subprojects where each
> subproject has a parent project .. and a project has many child sub projects
> another bunch of records reprensenting data for projects and linked projects
> .. same parent child relationship here
> another bunch representing project and linked people ..
>
> so there are two ways I was thinking this kind of data can be indexed
>
> 1. create a single store called lets say CollectionData. use dynamic fields
> to post all this different data but use a type field to identify the type of
> records . e.g. to post two docs one representing project->linkedproject and
> another project->linkedpeople info
>
> <doc>
> <id>123</id>
> <type>LinkedProjects</type>
> <childName_s>child project name</childName_s>
> <childStatus_s>child project status</childStatus_s>
> ...
> <parent_s>parent info</parent_s>
> ...
> </doc>
>
> <doc>
> <id>123</id>
> <type>LinkedPeople</type>
> <childName_s>child person name</childName_s>
> ...
> <parent_s>parent info</parent_s>
> ...
> </doc>
>
> now from the same store I can run queries to get the different data while
> restricting the resultset on one type of records using the fq param ..
>
> 2. approach would be to create multiple stores for each different type of
> records .. with pretty much the same schema but now we dont need the type
> field because linkedProjects are in a linkedProjects store and linkedPeople
> are in linkedPeople store .. only drawback i guess is that you could have a
> few stores
>
> my question to you guys is which approach makes more sense. I would
> appreciate any comments.
>
> Thanks
> Adeel
>