# Combining results of multiple transformations into a single final table

**URL:** <https://discourse.getdbt.com/t/combining-results-of-multiple-transformations-into-a-single-final-table/1133>\
**Category:** Archive\
**Created:** [May 8, 2020, 12:29pm UTC](https://discourse.getdbt.com/t/combining-results-of-multiple-transformations-into-a-single-final-table/1133 "2020-05-08T12:29:22Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![daniele.frigo](https://avatars.discourse-cdn.com/v4/letter/d/e56c9b/32.png) [@daniele.frigo](https://discourse.getdbt.com/u/daniele.frigo)\
**Post date:** [May 8, 2020, 12:29pm UTC](https://discourse.getdbt.com/t/combining-results-of-multiple-transformations-into-a-single-final-table/1133/1 "2020-05-08T12:29:22Z")

</div>

I’m trying to convert an ODI project into dbt (moving from Oracle target to Snowflake).  
In one datamart I have 5 different “sections” of data coming from different transformation processes that at the end I need to “merge” in the target table simply appending them.  
The original approach was to create 5 different workflows, executed in parallel, with 5 different INSERT INTO in the same table as last step.  
In dbt this is not possible (as far as I know); I can prepare 5 work tables and then do the final insert with 5 UNION ALL, but the original approach is probably better parallelized.  
How do you guys handle this kind of situations?  
Thanks  
Daniele

---

<div class="post-metadata">

**Author:** ![fabrice.etanchaud](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.getdbt.com/fabrice.etanchaud/32/595_2.png) [@fabrice.etanchaud](https://discourse.getdbt.com/u/fabrice.etanchaud)\
**Post date:** [May 11, 2020, 10:02am UTC](https://discourse.getdbt.com/t/combining-results-of-multiple-transformations-into-a-single-final-table/1133/2 "2020-05-11T10:02:02Z")

</div>

Hi @daniele.frigo, with dbt’s built-in parallelization, work tables should be prepared in parallel; why do you think it could be worse ? And should “inserting into separate datasets”, and then “unioning all” be a better option concerning locks ?

Best regards,

---

<div class="post-metadata">

**Author:** ![daniele.frigo](https://avatars.discourse-cdn.com/v4/letter/d/e56c9b/32.png) [@daniele.frigo](https://discourse.getdbt.com/u/daniele.frigo)\
**Post date:** [May 11, 2020, 10:26am UTC](https://discourse.getdbt.com/t/combining-results-of-multiple-transformations-into-a-single-final-table/1133/3 "2020-05-11T10:26:27Z")

</div>

The locking could be an issue on some databases, it strongly depends on the lock implementation of the specific vendor.  
The original implementation essentially skips one step, the last one where I actually do UNION ALL and insert in the final table (I did not explain that correctly in my previous post, it’s not a matter or parallelization, which is absolutely perfect with dbt).

---

<div class="post-metadata">

**Author:** ![joellabes](https://sea2.discourse-cdn.com/flex020/user_avatar/discourse.getdbt.com/joellabes/32/3980_2.png) [@joellabes](https://discourse.getdbt.com/u/joellabes)\
**Post date:** [September 13, 2022, 3:40am UTC](https://discourse.getdbt.com/t/combining-results-of-multiple-transformations-into-a-single-final-table/1133/4 "2022-09-13T03:40:47Z")

</div>

2 posts were split to a new topic: [Processing source tables with differing arrival times throughout day](https://discourse.getdbt.com/t/processing-source-tables-with-differing-arrival-times-throughout-day/4911)