P
(PeteCresswell)
We so a lot of calculations where we need to know the prior
business day or the date of two or three business days ago.
Prior weekdays, slam-dunk... no problem... all in memory, runs
like a flash.
Prior *business* days, we're getting killed by the I/O necessary
to go to a table of company holidays.
Only takes a fraction of a second, but it's used in iterative
processes. Typically we have to run through a hundred or two
hundred.... maybe even 2 thousand dates and discover the Nth
prior business day for each in order to come up with a computed
result.
Only thing I can think of is to get that determination of the
loop and batch it somewhere into a table that can be joined to.
Calendar never changes. Company holidays only change once a
year or so when somebody updates the table. Seems like we could
maintain a table with one row per calendar day and as many
columns as the max number of prior biz days we'd ever need.
Has anybody been here?
business day or the date of two or three business days ago.
Prior weekdays, slam-dunk... no problem... all in memory, runs
like a flash.
Prior *business* days, we're getting killed by the I/O necessary
to go to a table of company holidays.
Only takes a fraction of a second, but it's used in iterative
processes. Typically we have to run through a hundred or two
hundred.... maybe even 2 thousand dates and discover the Nth
prior business day for each in order to come up with a computed
result.
Only thing I can think of is to get that determination of the
loop and batch it somewhere into a table that can be joined to.
Calendar never changes. Company holidays only change once a
year or so when somebody updates the table. Seems like we could
maintain a table with one row per calendar day and as many
columns as the max number of prior biz days we'd ever need.
Has anybody been here?