# Document Structure Design **URL:** \ **Category:** Elasticsearch\ **Created:** [December 12, 2012, 7:48pm UTC](https://discuss.elastic.co/t/document-structure-design/10057 "2012-12-12T19:48:13Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![TeeTim](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/teetim/32/2370_2.png) [@TeeTim](https://discuss.elastic.co/u/TeeTim)\ **Post date:** [December 12, 2012, 7:48pm UTC](https://discuss.elastic.co/t/document-structure-design/10057/1 "2012-12-12T19:48:13Z")
In replacing the backed of an relational DB with ES, we're faced with the choice of structuring documents a couple of ways: (1) attribute : [{ adapterInstance : "ying", attributeName : "attribute1", attributeType : "java.lang.Integer", attributeValue : 24 } ] or (2) attributes : { adapterInstance : "ying", attribute : [{ attributeName : "attribute1", attributeType : "java.lang.Integer", attributeValue : 24, } ] (1) is how the data is typically received, one at a time, (2) is some aggregate business logic that associates the adapterInstance with an array of attributes. While this can be coded to support either document structure, for search would (2) give faster results knowing that the attribute (array) in either structure can be indexed (as a nested type)? -- ---
**Author:** ![radu\_gheorghe](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/radu_gheorghe/32/556_2.png) [@radu\_gheorghe](https://discuss.elastic.co/u/radu_gheorghe)\ **Post date:** [December 15, 2012, 2:17pm UTC](https://discuss.elastic.co/t/document-structure-design/10057/2 "2012-12-15T14:17:14Z")
Hello, I think it's best to structure your data in a way that suits best what you search for. So how does your typical query look like? What do you most often search for? The rule of thumb is that flat documents are easier to handle than nested documents. Nested documents are actually additional documents internally. ## Best regards, Radu [http://sematext.com/](http://sematext.com/) -- Elasticsearch -- Solr -- Lucene On Wed, Dec 12, 2012 at 9:48 PM, TeeTim [tim.sheridan@me.com](mailto:tim.sheridan@me.com) wrote: > In replacing the backed of an relational DB with ES, we're faced with the > choice of structuring documents a couple of ways: > > (1) > > attribute : [{ > adapterInstance : "ying", > attributeName : "attribute1", > attributeType : "java.lang.Integer", > attributeValue : 24 > } > ] > > or (2) > > attributes : { > adapterInstance : "ying", > attribute : [{ > attributeName : "attribute1", > attributeType : "java.lang.Integer", > attributeValue : 24, > } > ] > > (1) is how the data is typically received, one at a time, (2) is some > aggregate business logic that associates the adapterInstance with an array > of attributes. While this can be coded to support either document > structure, for search would (2) give faster results knowing that the > attribute (array) in either structure can be indexed (as a nested type)? > > -- -- ---
**Author:** ![phill](https://avatars.discourse-cdn.com/v4/letter/p/779978/32.png) [@phill](https://discuss.elastic.co/u/phill)\ **Post date:** [January 3, 2013, 1:12am UTC](https://discuss.elastic.co/t/document-structure-design/10057/3 "2013-01-03T01:12:22Z")
Picking up this thread, I think I can pass on a comment or two. Tim did not say that he was going to use nested documents as opposed to (1) hierarchical structure which is not technically "nested" in ES, but called "inner objects" in the documentation. (2) nested documents which as Radu says would be separate documents (3) parent child documents, in Tim's case, would maybe be adapter as parent and attribute as child. But, if you ever need to search on two or more values in an attribute matching, e.g. attribute.name:"length" AND attribute.value:10 then you would have to use either a nested or parent/child arrangement in order to avoid "cross object matches" for example given two doc's "adapter": { "instance":"ying", "attribute": [ { "name":"height", "value":"10"}, { "name":"width", "value":"5" } ] } "adapter": { "instance":"yang", "attribute": [ { "name":"height", "value":"5"}, { "name":"width", "value":"10" } ] } And the query like +attribute.name:"height"+"attribute.value":10 Using inner objects you would match ying and yang Using nested objects you would match only ying Using child objects and the appropriate has\_child or has\_parent as needed, you would match only ying. As Radu said, you want to build the structure which supports your queries. I would also design types and field names which don't repeat "attribute" everywhere (as I have done above). -Paul On 12/15/2012 6:17 AM, Radu Gheorghe wrote: > Hello, > > I think it's best to structure your data in a way that suits best what > you search for. > > So how does your typical query look like? What do you most often > search for? > > The rule of thumb is that flat documents are easier to handle than > nested documents. Nested documents are actually additional documents > internally. > > ## Best regards, Radu > > [http://sematext.com/](http://sematext.com/) -- Elasticsearch -- Solr -- Lucene > > On Wed, Dec 12, 2012 at 9:48 PM, TeeTim \<[tim.sheridan@me.com](mailto:tim.sheridan@me.com) > [mailto:tim.sheridan@me.com](mailto:tim.sheridan@me.com)\> wrote: > > ``` > In replacing the backed of an relational DB with ES, we're faced > with the choice of structuring documents a couple of ways: > > (1) > > |attribute : [|{ > |||adapterInstance : ||"ying",| > |||attributeName : ||"attribute1"||,| > |||attributeType : ||"java.lang.Integer"||,| > |||attributeValue : ||24| > |||}| > ] > > or (2) > > |attributes : {| > |adapterInstance : "ying",| > |attribute : |[{ > |||attributeName : ||"attribute1"||,| > |||attributeType : ||"java.lang.Integer"||,| > |||attributeValue : ||24||,| > |||}| > ] > > (1) is how the data is typically received, one at a time, (2) is > some aggregate business logic that associates the adapterInstance > with an array of attributes. While this can be coded to support > either document structure, for search would (2) give faster > results knowing that the attribute (array) in either structure can > be indexed (as a nested type)? > -- > > ``` > > -- -- ---
**Author:** ![TeeTim](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/teetim/32/2370_2.png) [@TeeTim](https://discuss.elastic.co/u/TeeTim)\ **Post date:** [January 3, 2013, 3:41pm UTC](https://discuss.elastic.co/t/document-structure-design/10057/4 "2013-01-03T15:41:36Z")
Thank you both so much. Your comments helped clarify my understanding. Tim On Wednesday, January 2, 2013 8:13:30 PM UTC-5, P Hill wrote: > Picking up this thread, I think I can pass on a comment or two. > Tim did not say that he was going to use nested documents > as opposed to > (1) hierarchical structure which is not technically "nested" in ES, but > called "inner objects" in the documentation. > (2) nested documents which as Radu says would be separate documents > (3) parent child documents, in Tim's case, would maybe be adapter as > parent and attribute as child. > > But, if you ever need to search on two or more values in an attribute > matching, e.g. attribute.name:"length" AND attribute.value:10 > then you would have to use either a nested or parent/child arrangement > in order to avoid "cross object matches" > for example given two doc's > "adapter": { "instance":"ying", "attribute": [ { "name":"height", > "value":"10"}, { "name":"width", "value":"5" } ] } > "adapter": { "instance":"yang", "attribute": [ { "name":"height", > "value":"5"}, { "name":"width", "value":"10" } ] } > > And the query like > +attribute.name:"height"+"attribute.value":10 > > Using inner objects you would match ying and yang > Using nested objects you would match only ying > Using child objects and the appropriate has\_child or has\_parent as > needed, you would match only ying. > > As Radu said, you want to build the structure which supports your queries. > > I would also design types and field names which don't repeat "attribute" > everywhere (as I have done above). > > -Paul > > On 12/15/2012 6:17 AM, Radu Gheorghe wrote: > > > Hello, > > > > I think it's best to structure your data in a way that suits best what > > you search for. > > > > So how does your typical query look like? What do you most often > > search for? > > > > The rule of thumb is that flat documents are easier to handle than > > nested documents. Nested documents are actually additional documents > > internally. > > > > ## Best regards, Radu > > > > [http://sematext.com/](http://sematext.com/) -- Elasticsearch -- Solr -- Lucene > > > > On Wed, Dec 12, 2012 at 9:48 PM, TeeTim \<[tim.sh...@me.com](mailto:tim.sh...@me.com) \ > > \<[mailto:tim.sh...@me.com](mailto:tim.sh...@me.com) \\>\> wrote: > > > > ``` > > In replacing the backed of an relational DB with ES, we're faced > > with the choice of structuring documents a couple of ways: > > > > (1) > > > > |attribute : [|{ > > |||adapterInstance : ||"ying",| > > |||attributeName : ||"attribute1"||,| > > |||attributeType : ||"java.lang.Integer"||,| > > |||attributeValue : ||24| > > |||}| > > ] > > > > or (2) > > > > |attributes : {| > > |adapterInstance : "ying",| > > |attribute : |[{ > > |||attributeName : ||"attribute1"||,| > > |||attributeType : ||"java.lang.Integer"||,| > > |||attributeValue : ||24||,| > > |||}| > > ] > > > > (1) is how the data is typically received, one at a time, (2) is > > some aggregate business logic that associates the adapterInstance > > with an array of attributes. While this can be coded to support > > either document structure, for search would (2) give faster > > results knowing that the attribute (array) in either structure can > > be indexed (as a nested type)? > > -- > > > > ``` > > > > -- -- ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:57am UTC](https://discuss.elastic.co/t/document-structure-design/10057/5 "2017-07-06T02:57:55Z")