In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   On Demand  |   Home  |

Integrated Methodology (Last Resort)
There are times when the sheer complexity of the staging and transformation processes makes the use of a parallel table path too difficult to set up. This is true for some fact tables, in particular those that do a lot of ranking, like the fact_om_order_history table. If an attempt has been made to create a parallel path and it is too difficult to achieve a satisfactory result, adding custom columns to the existing infrastructure can be allowed. Future patches and upgrade installations will have to take these into account and they will have to be reimplemented when they get disrupted. Inform the customer of this possibility as it requires an additional services engagement to reimplement the customizations.
Pros and Cons
Easier to do an initial implementation.
Ensures that the customization follows the same path that like data is moving through, eliminating risk of somehow getting the data connections wrong.
No need for keeping separate sets of views or staging tables.
Far more difficult to do upgrades or install patches as customization work needs to be reimplemented after the patch is applied. This is the number-one reason why this methodology is a last resort.
Creates difficulties for support in trying to determine how to resolve issues with the custom code.
There is some risk of disrupting existing logic if custom work is not done right. The implementer should be careful and aware of Cartesian joins.