# Hierarchical Documents **URL:** \ **Category:** Elasticsearch\ **Created:** [June 13, 2012, 8:47pm UTC](https://discuss.elastic.co/t/hierarchical-documents/8089 "2012-06-13T20:47:19Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Salman\_Haq](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/salman_haq/32/2849_2.png) [@Salman\_Haq](https://discuss.elastic.co/u/Salman_Haq)\ **Post date:** [June 13, 2012, 8:47pm UTC](https://discuss.elastic.co/t/hierarchical-documents/8089/1 "2012-06-13T20:47:19Z")
Hi, I am developing an application where I need to store, search, and manipulate complex hierarchical documents. A sample document can be seen here: > This document describes the schema a relational database and has an attribute called "tables" which is a list of dictionaries describing the tables in the database. Each dictionary has an attribute called "column" which is a list of dictionaries describing the columns in that table. I want to use ES as the backend to store this document and present different views for it. An example of view would be a grid displaying the 'name' and 'numRows' fields for all tables. Another example of view would be grid displaying the 'name', 'type' and 'remarks' fields for all the columns in the document, segmented by the table they belong to. If I store this information as a single monolithic document then I lose the ability to use ES to compute facets like how many columns of type 'X' exist. This approach also means that each view will have to pre-process the retrieved document before displaying it because the hierarchical information has to be flattened out. Alternatively, I can split the information into various document types, eg: column type, table type, etc, which contain information in manner that maps naturally to the views. The drawback of this approach is that a particular value could be stored in more than one document and an update will necessarily mean updating multiple documents to keep the information synchronized. I'm hoping someone from the community can provide some guidance with tips and best practices for dealing with this type of use case. If my use case is too much of an abuse of ES, then perhaps somebody can suggest alternative architectures, like using CouchDb as the backing store and integrating with ES via River for search. Thanks, Shaq ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [June 14, 2012, 9:49pm UTC](https://discuss.elastic.co/t/hierarchical-documents/8089/2 "2012-06-14T21:49:28Z")
You will have to experiment with it. Check parent child relationships, also, you might need to denormalize your data. On Wed, Jun 13, 2012 at 10:47 PM, Salman Haq [salman.haq@gmail.com](mailto:salman.haq@gmail.com) wrote: > Hi, > > I am developing an application where I need to store, search, and > manipulate complex hierarchical documents. A sample document can be seen > here: > > [A complex hierarchical JSON document ยท GitHub](https://gist.github.com/2926316) > > This document describes the schema a relational database and has an > attribute called "tables" which is a list of dictionaries describing the > tables in the database. Each dictionary has an attribute called "column" > which is a list of dictionaries describing the columns in that table. > > I want to use ES as the backend to store this document and present > different views for it. > > An example of view would be a grid displaying the 'name' and 'numRows' > fields for all tables. > Another example of view would be grid displaying the 'name', 'type' and > 'remarks' fields for all the columns in the document, segmented by the > table they belong to. > > If I store this information as a single monolithic document then I lose > the ability to use ES to compute facets like how many columns of type 'X' > exist. > This approach also means that each view will have to pre-process the > retrieved document before displaying it because the hierarchical > information has to be flattened out. > > Alternatively, I can split the information into various document types, > eg: column type, table type, etc, which contain information in manner that > maps naturally to the views. > The drawback of this approach is that a particular value could be stored > in more than one document and an update will necessarily mean updating > multiple documents to keep the information synchronized. > > I'm hoping someone from the community can provide some guidance with tips > and best practices for dealing with this type of use case. If my use case > is too much of an abuse of ES, then perhaps somebody can suggest > alternative architectures, like using CouchDb as the backing store and > integrating with ES via River for search. > > Thanks, > Shaq ---
**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, 3:24am UTC](https://discuss.elastic.co/t/hierarchical-documents/8089/3 "2017-07-06T03:24:04Z")