I have a fact table that needs a join to a dimension table however obtaining that relationship from the source data isn’t easy. The fact table is loaded from a source table that has around a million rows, so in accordance with best practice, I’m using a previous run date to only select the source rows that have been added since the previous run. After getting the rows I wish to load I need to go through 3 other tables in order to be able to do the lookup to the dimension table. Each of the 3 tables also has around a million rows.
I’ve read that best practice says not to extract source data that you know won’t be needed. And best practice also says to have as light-touch as possible on the source system and therefore avoid sql joins. But in my case, those two best practices become mutually exlusive. If I only extract changed rows in the itermediary tables then I’ll need to do a join in the source query. If I extract all the rows from the source system then I’m extracting much more data than I need and that may cause SSIS memory/performance problems.
I’m leaning towards a join in the extraction of the source data but I’ve been unable to find any discussions on the merits and drawbacks of that approach. Would that be correct or incorrect? (The source tables and the DW tables are in Oracle).
Can you stage the 3 source tables that you are referencing? You may not need them in the DW, but you could have them sitting in a staging database purely for this purpose. You would still need to keep these up-to-date however, but assuming you can just pull over the changes, this may not be too bad.