Re: Tables and ring-like data structure?

"Ramon F Herrera" <ramon_at_conexus.net> schrieb im Newsbeitrag news:c9bc36ff.0308132238.3fbd483e_at_posting.google.com...
> I just started to design a payroll application for several
> different companies, some of them pay weekly, others
> byweekly or monthly. We have to keep the payment info for
> every pay period. A simple example:
>
> John Smith 1234.45 1/1/2003
> 1188.92 1/15/2003
> 1252.21 2/1/2003
> [...]
> 1234.45 12/31/2003
>
> In cases like this I find the relational paradigm too restrictive.
> Being a C programmer I keep on thinking on a ring-buffer like
> in which I dont have to move all those values from a field to
> the next every payday. Obviuosly I can only keep, say 52 pay
> periods, I could have a 52 element ring and everytime I get new
> data it overwrites the oldest pay period and some pointer gets
> to the next element (as opposed to rewriting all those
> current_date - 1 => current_date - 2, etc).
>
> I recently found out about the new object features of Oracle
> (I knew about them, but I hadn't seen actual code) which made
> me think that once the "relational" constraints have been
> shattered, perhaps I could somehow get out of that straight
> jacket (sorry, relational purists, I need the performance).
> Perhaps I need to have an array inside the tables and somehow
> keep the index modulo 52?
>
> Thanks for your experienced insight in this area...
>
> Regards,
>
> -Ramon F. Herrera

Hi, Ramon,

I donīt think it must be a ring, when I look on Your example, it is simply an 1:N relationship from a PERSON (1) to a PAYMENT_HISTORY (N), which would then grow in steps of one record per person per day. Data not needed anymore could the be
extracted to another table e.g. OLD_PAYMENTS, or they could be deleted, in order to have almost only "actual" data
in the PAYMENT table.

Thus You would not have a limitation to a number like 52, which You would always have in a ring structure.

hth, Jan Received on Thu Aug 14 2003 - 02:29:16 CDT