Home Forums Data Warehousing Strategies and Ideas Capturing the Reason For Change for Type 2 changes RE: Capturing the Reason For Change for Type 2 changes

  • March 5, 2014 at 3:17 pm

    #1694512

    Lempster (3/3/2014)

    Jeff Moden (2/28/2014)

    Put an index on the "Current-Flag" and watch your GUI's timeout when they try to do an INSERT because of the massive extent splits that will occur. 😉 I recommend just doing the dates correctly.

    I'm talking about a Data Warehouse so there aren't going to be any GUIs to timeout, certainly not any doing inserts. There will of course be inserts on a daily basis due to the ETL process. The relational tables in the Data Warehouse will have multidimensional cubes built on them and it will be the cubes that are queried by end users, not the relational tables directly.

    I will of course undertake extensive testing, but at this point I'm inclined to follow Kimball best practice.

    Regards

    Lempster

    My incliniation is that it doesn't matter where the inserts are coming from. A leading or singular column in an index with such low selectivity is going to cause massive extent splitting that will slow any process down.

    Although I'm also inclined to go with what experts say, it does cause me concern when the best practices of one expert or group of experts is contrary to the best practices of another. Testing would be a good thing here.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)