• pietlinden (3/13/2016)


    No, I'm using the Calendar table as a Dimension so I can lump sales etc into "bins" -- summarize by Year/Month whatever.

    While that works and can be fairly well effective, I find that a totally non-intuitive and somewhat unorthodox method for lumping report items together works very well without giving up much in the line of flexibility. Rather than trying to do your binning by joining, I've found that it's much more effective to add persisted computed columns to the source table with the formula to calculate the 1st day of the month, week, quarter, or year. It's a bit like using a materialized (indexed) view but without that little bit of heartache. And, those columns can be indexed! In fact they can be indexed to include other columns so that a trip to the table isn't even necessary until after the aggregation is complete and you just need to add some "labels" to it. An added benefit is that since the indexes would have the temporally based columns as the leading column, they would rarely require any defragmentation.

    Of course, since monthly sales don't change after they've been entered, perhaps a preaggregated table containing older aggregations unioned with a query of current data would also speed up the process.

    --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)