P
(PeteCresswell)
Two tables:
tblPaymentAccrualDaily
SecID PayDate PayAmount
003 01/01/2007 123.97
004 01/01/2007 4250.63
003 01/02/2007 123.43
003 01/03 2007 120.45
003 01/04/2007 119.20
003 01/05/2007 130.44
...and so on for each and every day
tblPaymentSchedule
SecID PayDate
003 01/03/2007
003 02/03/2007
003 03/05/2007
003 04/03/2007
What I want to do is present, for a given SecID, the total daily
accruals from tblPaymentSchedule.PayDate to the next (actually,
the day after one PayDate to the next).
At any time, the user can alter the dates within PaymentSchdule.
The easy path would be to denormalize the totals into
tblPaymentSchedule, populate them once, put in some code
to re-populate them if/when a date is changed, and be done with
it.
I'd prefer, however, to do it all on-the-fly keeping things
normalized. But I also need for it to happen quickly enough to
not slow down the loading of a "Security Detail" screen.
Bottom Line: is this something I could do via SQL without abusing
SQL? i.e. would an SQL solution scale to where a security
might have a year or two worth of accruals behind it or would it
start bogging down?
tblPaymentAccrualDaily
SecID PayDate PayAmount
003 01/01/2007 123.97
004 01/01/2007 4250.63
003 01/02/2007 123.43
003 01/03 2007 120.45
003 01/04/2007 119.20
003 01/05/2007 130.44
...and so on for each and every day
tblPaymentSchedule
SecID PayDate
003 01/03/2007
003 02/03/2007
003 03/05/2007
003 04/03/2007
What I want to do is present, for a given SecID, the total daily
accruals from tblPaymentSchedule.PayDate to the next (actually,
the day after one PayDate to the next).
At any time, the user can alter the dates within PaymentSchdule.
The easy path would be to denormalize the totals into
tblPaymentSchedule, populate them once, put in some code
to re-populate them if/when a date is changed, and be done with
it.
I'd prefer, however, to do it all on-the-fly keeping things
normalized. But I also need for it to happen quickly enough to
not slow down the loading of a "Security Detail" screen.
Bottom Line: is this something I could do via SQL without abusing
SQL? i.e. would an SQL solution scale to where a security
might have a year or two worth of accruals behind it or would it
start bogging down?