# Relationship best practices
**URL:** https://discuss.elastic.co/t/relationship-best-practices/83558
**Category:** Elasticsearch
**Created:** [April 25, 2017, 11:34am UTC](https://discuss.elastic.co/t/relationship-best-practices/83558 "2017-04-25T11:34:33Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@vic-volk](https://discuss.elastic.co/u/vic-volk)
#### Post date: [April 25, 2017, 11:34am UTC](https://discuss.elastic.co/t/relationship-best-practices/83558/1 "2017-04-25T11:34:33Z")
Hi!
I want to ask about the best practice for design index data for related structures.
For example (customers and related orders):
```
customer: {
id: "...",
name: "...",
...
}
order: {
id: "",
customer_id: "...",
product_name: "...",
product_description: "...",
...
}
```
I want to find customers by order details.
How should I store this structure?
I know several ways: parent-child relationship or nested documents.
But I think, that is too redundant and expensive. Order details can be changed and customer details can be changed too (not at the same time).
Can I retrieve customers by steps?:
GET /orders (retrieve customer\_ids)
GET /customers (by retrieved ids and other customer data)
Can it be done by means of multi search API:
> **[Multi search API | Elasticsearch Guide \[8.11\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-multi-search.html)**
It allows to store customers and orders in separate indexes.
PS. Apache Solr has simple Join mechanism for the same purpose.
[https://wiki.apache.org/solr/Join](https://wiki.apache.org/solr/Join)
I also read:
> [@Best practices for related and hierarchical data](https://discuss.elastic.co/t/best-practices-for-related-and-hierarchical-data/63895):
>
> I'm new to elastic search and am grappling with how best to structure or not structure my model. For Example 1000's of users belong to a few hundred parent users and I want to record an indefinite amount of activity of all users. I'm guessing I'd do something like this: \* Index\_name/Users: { name, age, account, parent\_account, activity: [{ activity\_name, activity\_info, time}, {}, {}, {} ....] Does …
---
### Author:  [@xeraa](https://discuss.elastic.co/u/xeraa)
#### Post date: [April 29, 2017, 4:00pm UTC](https://discuss.elastic.co/t/relationship-best-practices/83558/2 "2017-04-29T16:00:17Z")
> [@vic-volk](#):
>
> too redundant and expensive
That will depend on your access patterns and what you see as cost. For some people more latency (because they need to resolve parent-child or do multiple queries) is expensive, for others disk and memory are expensive. That's really up to your use, queries, and what you see as your main cost.
The decision between parent-child vs application-side join is how you will most likely access your data. If the majority of your queries will need to access them together, parent-child would make sense. If you frequently want to access the entities independently, the application-side join is probably better.
While you can use multi-search, you'd need to know what you are searching in the initial query. I assume what you want is a search on `orders`, then your application extracts all `customer_ids` from that and can finally do a [multi-get](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-multi-get.html) on all of those IDs.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [May 27, 2017, 4:11pm UTC](https://discuss.elastic.co/t/relationship-best-practices/83558/3 "2017-05-27T16:11:56Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.