DATE lookup table (1990/01/01:2041/12/31)

Question

I use a DATE\'s master table for looking up dates and other values in order to control several events, intervals and calculations within my app. It has rows for every single day

Answer 1

The cool way of generating a rowset of dates in Oracle is to use the hierarchical query functionality, connect by. I have posted an example of this usage in another thread.

It gives a lot of flexibility without the PL/SQL overhead of a pipelined function.

Answer 2

This is a reasonable way of doing things. If you look into data warehousing, you'll find that those systems often use a similar system for the time fact table. Since there are less than 20K rows in the fifty-year span you're using, there isn't a huge amount of data.

There's an assumption that the storage gives better performance than doing the computations; that most certainly isn't clear cut since the computations are not that hard (though neither are they trivial) and any disk access is very slow in computational terms. However, the convenience of having the information in one table may be sufficient to warrant having to keep track of an appropriate method for each of the computed values stored in the table.

Answer 3

It depends on which database you are using. SQL Server has horrible support for temporal data and I almost always end up using a date fact table there. But databases like Oracle, Postgres and DB2 have really good support and it is typically more efficient to calculate dates on the fly for OLTP applications.

For instance, Oracle has a last_day() function to get the last day of a month and an add_months() function to, well, add months. Typically in Oracle I'll use a pipelined function that takes start and end dates and returns a nested table of dates.

Answer 4

OK, so I tested my app using 31 days/month to calculate interest rates & pawnshops are happy with it! Local Law prays as follows: From pawn or last int. pymt. date to 5 elapsed days, 5% interest on principal, 6 to 10 days = 10%, 11 to 15 days = 15%, and 16 days to 1 "month" = 20%.

So the interest table is now defined as follows:

NUMBER OF ELAPSED DAYS SINCE
PAWN DATE OR LAST INTEREST PYMT

 FROM     TO  ACUMULATED
  DAY    DAY    INTEREST
-----   ----  ----------
    0      5       5.00%
    6     10      10.00%
   11     15      15.00%
   16     31      20.00%
   32     36      25.00%
   37     41      30.00%
   42     46      35.00%
   47     62      40.00%

   [... until day 90 (forfeiture allowed)]
   from day 91 to 999, daily prorate based on 20%/month.

Did something bad happen in the UK on MAR-13 or SEP-1752?