>>Could you exlain more about this?
>
>Generally speaking, a data mart is a denormalized set of tables that are usually synthesized in a way to optimize queries.
>
>Just like OLTP database tables are usually normalized to post data as efficiently as possibly, data mart (and data warehouse) tables are usually less normalized, for frequent queries.

As an easy-to-do-yourself intermediate step I often propose vertical partitioning (Yearly, Monthly, Weekly), as by this you reap quite a few side benefits:
- reindexing the "current" table can be done more often, as the table size is minimal
- reindexing the "history" table might be less problematic in write-heavy situations - for instance if reading from it is not done as often as writing new data
- no denormalization effort, query "all" data as datastructures in "current" and "history" table are identical, only needing a union (probably could be written as union all)

>But it means a period of posting new transaction data to the data mart. Some people do it nightly, others weekly....and some will do it every 30 minutes.

and the shuffling off the hot tables is probably faster as well ;-)

>Of course, that means a lag, between when data is posted to txaction tables, and when they appear in the data mart. For some, that lag is OK. Others find it unacceptable.
>SQL 2012 and 2014 enterprise have introduced some new data warehousing type features that help with the lag.
>
>This is just an extremely brief overview. But it does sound like you might have some overloading in the process, and a data mart can sometimes help. More details would need to be covered to see if this would really help, but I do think it's something to at least consider.

the in-between step IMO makes sense if the current situation is still tolerable - the speed benefits might make it "good" again without costly external help AND the often more expensive technical debt you incur for future data changes: you will have to consider hot AND data mart table layout in the future for ANY changes, incurring greater cost if you decide to implement anything more convoluted than the easy steps outlined above ;-)