# Best Approach to taking a large(ish) sql table into ES **URL:** \ **Category:** Elasticsearch\ **Created:** [June 10, 2013, 7:10am UTC](https://discuss.elastic.co/t/best-approach-to-taking-a-large-ish-sql-table-into-es/12341 "2013-06-10T07:10:58Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Julian\_3](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/julian_3/32/103539_2.png) [@Julian\_3](https://discuss.elastic.co/u/Julian_3)\ **Post date:** [June 10, 2013, 7:10am UTC](https://discuss.elastic.co/t/best-approach-to-taking-a-large-ish-sql-table-into-es/12341/1 "2013-06-10T07:10:58Z")
hi, Kinda new to this so not sure if im thinking about this the wrong way, i have a MS SQL table with +- 50 columns that contain numbers or identifiers, no comments columns. do you create one index and load all values into there like this "card":"12345", "active":"0", "date":"1988-04-24", "from":"hero", "first\_name":"game", "last\_name":"there", ....etc or do you have to create many indexes for each column that you want to be able to search by. do you have to insert that data into multipe indexes? also does this mean that you have to reindex every time new data is added to the index ? (dosnt that cause downtime?) should you create new indexes of a daily basis? sorry i cant seem to find any links to best practises with elasticsearch, any help is greatly appreciated. -- 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). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [June 11, 2013, 4:33pm UTC](https://discuss.elastic.co/t/best-approach-to-taking-a-large-ish-sql-table-into-es/12341/2 "2013-06-11T16:33:56Z")
Lots of questions. Direct answers to some question in inline, but I would answer the "main" on on top. The easiest way to think of a RDBMS -\> Lucene translation is that each row in the table is a document in an index. Each column in the table is simply a field in the document. The hardest part of the translation is when you have multiple dependent tables since JOINs are not fully supported. However, if you have only one table, then the translation is straight forward. Having multiple indices will not help you since you will not be able to query on multiple columns/fields. On Mon, Jun 10, 2013 at 12:10 AM, Julian [julian.g.purse@gmail.com](mailto:julian.g.purse@gmail.com) wrote: > also does this mean that you have to reindex every time new data is added to the index ? > > You need to index the new data, but there is no new to reindex existing > data if it has not changed. > (dosnt that cause downtime?) > > There is no downtime. You can index to an existing live index. > should you create new indexes of a daily basis? I depends on your use case. Daily indices makes sense for time-sensitive data that is routinely purged. I would assume most do you use daily indices. > sorry i cant seem to find any links to best practises with elasticsearch, any help is greatly appreciated. Searching the mailing list archives for specific questions is probably your best bet. There is no one single best way to do things since everyone's system is different. Cheers, Ivan -- 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). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**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, 2:31am UTC](https://discuss.elastic.co/t/best-approach-to-taking-a-large-ish-sql-table-into-es/12341/3 "2017-07-06T02:31:46Z")