# Porting a relational structure to Elasticsearch - Nested or Parent/Child

**URL:** <https://discuss.elastic.co/t/porting-a-relational-structure-to-elasticsearch-nested-or-parent-child/32920>\
**Category:** Elasticsearch\
**Created:** [October 24, 2015, 8:50pm UTC](https://discuss.elastic.co/t/porting-a-relational-structure-to-elasticsearch-nested-or-parent-child/32920 "2015-10-24T20:50:27Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![ziv2081](https://avatars.discourse-cdn.com/v4/letter/z/d2c977/32.png) [@ziv2081](https://discuss.elastic.co/u/ziv2081)\
**Post date:** [October 26, 2015, 9:47pm UTC](https://discuss.elastic.co/t/porting-a-relational-structure-to-elasticsearch-nested-or-parent-child/32920/3 "2015-10-26T21:47:41Z")

</div>

That's a good decision flow 😛  
Do you have ram limits?  
parent/child joins are held in memory so you have to calculate or estimate the amount of relationships.

Nested documents are a bit of a pain, you'd have to make some groovy scripts to update or do application side updates to the entire document.  
Also considering the amount of events you have, there is a max of 2B documents a shard can hold ( including nested).

How about flattening it this way:  
Age, Gender, Wave, Time, EVENT1, EVENT2 etc.. dynamically added to the type.  
ie:  
{ age: 49,  
gender: M,  
wave: 0,  
timestamp: 4/20/2095,  
event1: V39  
}  
each event will be created this way.  
If you don't have storage limits this could be easy to manage.  
Also elastic search has some pretty nice compression for repeating values..

---

_[View the full topic](https://discuss.elastic.co/t/porting-a-relational-structure-to-elasticsearch-nested-or-parent-child/32920)._