Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
lfalmoguera
Creator
Creator

Split Original Huge data into multiple ones.

Hi all, 

thanks a lot in advance for the help.

I am looking forward a more efficient way to "allocate" data from a huge data table into other more little ones.

I have +1000M registers table and I want to split it into other more little NoConcatenate ones.

For example. I have this table:

monthfield1value
201901AA1
201902AA2
201903AA3
201904AA4
201905AA5
201906AA6
201907AA7
201908AA8
201909AA9
201910AA10
201911AA11
201912AA12
201901BB1
201902BB2
201903BB3
201904BB4
201905BB5
201906BB6
201907BB7
201908BB8
201909BB9
201910BB10
201911BB11
201912BB12

 

Imagine I want to split the data into as many tables as combinations between month&field1

Is there any way to do it straightforward without doing a loop with different where conditions?

It consumes too mucho time by iterating the original table every loop.

Thanks!

Labels (1)
1 Solution

Accepted Solutions
marcus_sommer

I think there is no way to avoid a loop with appropriate where-statements but it doesn't need to happens with the origin table else you could pull the whole table (and if no usable key is available because it should be a from several fields combined one - you should create that key as this point) and store it as qvd and then using the qvd to loop through by applying a where exists(YOURKEY) to ensure that they are loaded in an optimized mode and then storing your slices.

Before doing it I suggest to consider if it's really suitable to create for each period + other field an own table. Of course there are various benefits to slice bigger datasets but if it ends in hundreds or even thousands of rather small tables you may get more and more disadvantages because the overhead to the table-handling may increase significantly and might be higher than the pure data-loading.

- Marcus

View solution in original post

3 Replies
marcus_sommer

I think there is no way to avoid a loop with appropriate where-statements but it doesn't need to happens with the origin table else you could pull the whole table (and if no usable key is available because it should be a from several fields combined one - you should create that key as this point) and store it as qvd and then using the qvd to loop through by applying a where exists(YOURKEY) to ensure that they are loaded in an optimized mode and then storing your slices.

Before doing it I suggest to consider if it's really suitable to create for each period + other field an own table. Of course there are various benefits to slice bigger datasets but if it ends in hundreds or even thousands of rather small tables you may get more and more disadvantages because the overhead to the table-handling may increase significantly and might be higher than the pure data-loading.

- Marcus

Brett_Bleess
Former Employee
Former Employee

Did Marcus' post get you what you needed?  If so, do not forget to close out the thread by using the Accept as Solution button on his post.  If you did something different, consider posting that and then use the button to mark that as the solution.  If you are still working on things, leave an update.

Regards,
Brett

To help users find verified answers, please do not forget to use the "Accept as Solution" button on any post(s) that helped you resolve your problem or question.
I now work a compressed schedule, Tuesday, Wednesday and Thursday, so those will be the days I will reply to any follow-up posts.
lfalmoguera
Creator
Creator
Author

Thanks a lot for the answer Marcus!