# Same field name with different data types in the same index **URL:** \ **Category:** Elasticsearch\ **Created:** [October 24, 2016, 1:54pm UTC](https://discuss.elastic.co/t/same-field-name-with-different-data-types-in-the-same-index/63758 "2016-10-24T13:54:30Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![fabiocatalao](https://avatars.discourse-cdn.com/v4/letter/f/779978/32.png) [@fabiocatalao](https://discuss.elastic.co/u/fabiocatalao)\ **Post date:** [October 24, 2016, 1:54pm UTC](https://discuss.elastic.co/t/same-field-name-with-different-data-types-in-the-same-index/63758/1 "2016-10-24T13:54:30Z")
Hi! I'm starting to work with Elasticsearch and I'm having some issues designing a schema that enables the possibility of having different data types on the same field name. I’m planning to save my documents at index\_name/customer\_id/\_id. My customers will have the possibility to define custom fields that will be replicated to Elasticsearch. It could produce data type collisions as someone create a field with the same name and different data type of an existing field. A simple example could be the import of a CSV where a birthdaydate can be defined as string by a costumer and as date by other customer. I’m thinking about adding a suffix to the field name, such as birthdaydate\_s or birthdaydate\_d. Do you think it is an acceptable solution to it? I've found a solution that recommends adding multiple sub-fields according to datatype but I think it will dramatically increase indexes size. Thanks, Fábio ---
**Author:** ![mainec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mainec/32/5557_2.png) [@mainec](https://discuss.elastic.co/u/mainec)\ **Post date:** [October 25, 2016, 9:16am UTC](https://discuss.elastic.co/t/same-field-name-with-different-data-types-in-the-same-index/63758/2 "2016-10-25T09:16:41Z")
> [@fabiocatalao](#): > > I've found a solution that recommends adding multiple sub-fields according to datatype but I think it will dramatically increase indexes size. Can you elaborate why you think this would dramatically increase the index size? Also it would be awesome if you could share a link to the resources where you found the recommended approach you sketched. Isabel ---
**Author:** ![fabiocatalao](https://avatars.discourse-cdn.com/v4/letter/f/779978/32.png) [@fabiocatalao](https://discuss.elastic.co/u/fabiocatalao)\ **Post date:** [October 25, 2016, 9:50am UTC](https://discuss.elastic.co/t/same-field-name-with-different-data-types-in-the-same-index/63758/3 "2016-10-25T09:50:19Z")
> [@mainec](#): > > Can you elaborate why you think this would dramatically increase the index size? My solution will lead to a lot of sparsity as different customers could have a lot of different custom fields. The use of a solution that enables the possibility of having different multiple subfields to each found datatype will expand this problem. However, it is a fact that adding a suffix will also lead to a lot of sparsity on the data... I've just thought about this option as I've previously worked on a _platform_ where there wasn't subfields and it has been chosen as the solution. Do you think that the use of subfields is the most common and effective way to solve problems like mine? ---
**Author:** ![mainec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mainec/32/5557_2.png) [@mainec](https://discuss.elastic.co/u/mainec)\ **Post date:** [October 25, 2016, 10:22am UTC](https://discuss.elastic.co/t/same-field-name-with-different-data-types-in-the-same-index/63758/4 "2016-10-25T10:22:15Z")
I'm actually not sure what is most common for your problem. Using sub-fields/ multi fields makes sense when fields should be stored in multiple ways, e.g. using more than one analyzer. Re-reading your original post this is different from your use-case though: [https://www.elastic.co/guide/en/elasticsearch/reference/current/multi-fields.html](https://www.elastic.co/guide/en/elasticsearch/reference/current/multi-fields.html) The information in here [https://www.elastic.co/blog/great-mapping-refactoring#conflicting-mappings](https://www.elastic.co/blog/great-mapping-refactoring#conflicting-mappings) on how to resolve conflicting mappings might make more sense in your case. Also depending on how many customers you expect, you might want to read [https://www.elastic.co/guide/en/elasticsearch/guide/current/user-based.html](https://www.elastic.co/guide/en/elasticsearch/guide/current/user-based.html) and for contrast [https://www.elastic.co/blog/found-multi-tenancy](https://www.elastic.co/blog/found-multi-tenancy) first. Hope this helps, Isabel ---
**Author:** ![fabiocatalao](https://avatars.discourse-cdn.com/v4/letter/f/779978/32.png) [@fabiocatalao](https://discuss.elastic.co/u/fabiocatalao)\ **Post date:** [October 26, 2016, 9:19am UTC](https://discuss.elastic.co/t/same-field-name-with-different-data-types-in-the-same-index/63758/5 "2016-10-26T09:19:19Z")
Thank you for your reply. I've read some of the posts you cited, but the third one gave me a new perspective about some issues! 🙂 The sparsity problems I was afraid were already fixed. They were almost related to a lucene issue: [https://issues.apache.org/jira/browse/LUCENE-6863](https://issues.apache.org/jira/browse/LUCENE-6863) . I will try to do some tests about the use of sub-fields and I will later give my feedback. ---
**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\ **Post date:** [October 26, 2016, 9:29am UTC](https://discuss.elastic.co/t/same-field-name-with-different-data-types-in-the-same-index/63758/6 "2016-10-26T09:29:45Z")
I saw what sounds like a similar scenario recently with a business who had lots of customers each of whom could pick their own choices of field names but shared a common index. Their solution was to have a reserved bank of elasticsearch fields (e.g. intField1, intField2.... stringField1...) in the mapping and each customer would have their field choices logically mapped to these physical fields e.g: ``` customer 1's "myPageViews" field == intField1 customer 2's "widgetSales" field == intField1 customer 2's "widgetSKU" field == stringField1 ``` Then each customer query went through a custom mapping layer to translate their logical request into the physical elasticsearch query. This helped ensure there was a sensible limit on the number of unique fields in the elasticsearch mapping and that there were no naming/type conflicts. Cheers Mark ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:09pm UTC](https://discuss.elastic.co/t/same-field-name-with-different-data-types-in-the-same-index/63758/7 "2017-07-05T22:09:37Z")