I have a table that manages several types of transactions sent to our payroll system. Recently a requirement came down that we be able to split our transactions into multiple transactions to a payroll, but look like a single transaction to the user. So one transaction for a deduction of $100 from a paycheck would be split into one $50 deduction this pay period, and one $50 deduction next pay period, yet look like a single deduction of $100 from the users point of view.

My initial thought is to create a second "wrapper" table. This table would contain one record as a reference to multiple related transactions in the existing transaction table (which would require slight modifications to include a pointer to this parent wrapper table record).

Assuming this is the route to go, would it be more efficient to simply use a GROUP BY clause to aggregate the sum of the transactions (maybe inside of a view), or is there a better way of calculating the data of the related transactions?

Maybe the "wrapper" table isn't the way to go... any other suggestions?