# Feedback on Document Structure (and Inefficiencies)

**URL:** <https://discuss.elastic.co/t/feedback-on-document-structure-and-inefficiencies/23589>\
**Category:** Elasticsearch\
**Created:** [May 8, 2015, 6:05pm UTC](https://discuss.elastic.co/t/feedback-on-document-structure-and-inefficiencies/23589 "2015-05-08T18:05:48Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![James\_Addison](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@James\_Addison](https://discuss.elastic.co/u/James_Addison)\
**Post date:** [May 8, 2015, 6:05pm UTC](https://discuss.elastic.co/t/feedback-on-document-structure-and-inefficiencies/23589/1 "2015-05-08T18:05:48Z")

</div>

I'm looking to see if I can structure my current document schema better for  
the functionality we're providing - or maybe it's the queries that need  
improvement. Everything is working fine, but I can't help but see  
inefficiencies. Keep in mind that this is based on relational data from a  
Django project.

The basic idea is we have two types of Activities: Events and Classes.

An Event is a much simplified version of a Class - it's essentially a  
series of dates, each with a start and end time. The dates are usually  
sequential and while the times are usually the same, they can differ (the  
last day in the Event's date sequence might end earlier, for example).

A Class is more complex:

- each Class has one or more Sessions
- each Session has one or more 'session\_data' structures, which  
holds days of the week (represented by a list of numbers, from 0-6), start  
and end dates, and start/end times
- reason for this is that a Session might happen from May 6 to Sept 8 on  
Tuesdays at 8pm and Thursdays at 7:30pm - two 'session\_data' structures are  
needed to maintain this

Each Event and Class is indexed in Elasticsearch with the same document  
mapping 'activity' with a 'type' field. This is trimmed for brevity:

{  
"properties": {  
"type": {  
"type": "long"  
},  
"name": {  
"type": "string"  
},  
"dates": {  
"type": "date",  
"format": "dateOptionalTime"  
},  
"sessions": {  
"properties": {  
"session\_data": {  
"properties": {  
"days\_of\_week": {  
"type": "long"  
},  
"end": {  
"type": "date",  
"format": "dateOptionalTime"  
},  
"end\_time": {  
"type": "date",  
"format": "hour\_minute"  
},  
"start": {  
"type": "date",  
"format": "dateOptionalTime"  
},  
"start\_time": {  
"type": "date",  
"format": "hour\_minute"  
}  
}  
},  
"end": {  
"type": "date",  
"format": "dateOptionalTime"  
},  
"start": {  
"type": "date",  
"format": "dateOptionalTime"  
}  
}  
}  
}  
}

In our product, we never show Events happening in the past - we base it  
completely on upcoming 'dates' - the same concept holds for Classes, but we  
base it on 'sessions.start'.

So 'session\_data' and 'dates' are not separate documents at all, they're  
embedded in the 'activity' document. For Classes in particular, I'd like to  
pull out 'session\_data' into another document type/mapping with a '\_parent'  
to 'activity', but when we're returning results in our product we don't  
want to display duplicate items. In fact, we want to display the Class  
information along with the 'session\_data' underneath in our search results  
listing  
(see [http://www.chatterblock.com/camps-and-classes/victoria-british-columbia-c4098/?classes=y](http://www.chatterblock.com/camps-and-classes/victoria-british-columbia-c4098/?classes=y)  
for a working demo).

To get that result, I have to do some looping date checking in my Django  
view/template code to ensure I only display relevant (ie. upcoming, not  
past) Sessions. This is the particularly inefficient bit I'm talking  
about. Sometimes there are MANY Sessions in an activity.

I have a feeling that the new inner\_hits functionality might apply here,  
but I think I'll get into a 'grandparent' relationship scenario (two levels  
of parent relationships) as there's an existing relationship between  
'activity' and another document type called 'business' (who's running the  
Event or Class).

I really hope that this writeup wasn't too confusing! Everything 'works' at  
the moment, but Class listings are slower than other listings we've got,  
which is why I'm digging into inefficiencies to deal with this as we're  
growing nicely.

Thanks,  
James

## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/)

You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/9a4e3285-5001-4bd0-a9cf-1178635ebd54%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/9a4e3285-5001-4bd0-a9cf-1178635ebd54%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**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, 12:15am UTC](https://discuss.elastic.co/t/feedback-on-document-structure-and-inefficiencies/23589/2 "2017-07-06T00:15:00Z")

</div>