Re: Tables and ring-like data structure?

Without knowing too much about this, a possible table would be:

PAYMENT_HISTORY
(employee_id number(6),
 payment_date date
 payment_amount number(8,2));

with employee_id, payment_date being primary key (Note that some people prefer to use a separate column which contains a unique sequence number as the primary key).

-- 
Terry Dykstra
Canadian Forest Oil Ltd.
"Ramon F Herrera" <ramon_at_conexus.net> wrote in message
news:c9bc36ff.0308141238.67d3feb7_at_posting.google.com...


> Jan:

>

> Thanks a lot for your reply.  I am not sure I understand

> the actual implentation, though.  It seems to me that you

> suggest I should create one table for every employee,

> something like this:

>

>     PAYMENT_HISTORY_OF_<ssn here>

>         paymente date;

>         payment amount;

>

> (is that it?)  If that's the case I would end up with a

> really big number of tables.  BTW: I have done that in the

> past, for performance. Is that good?  Am I breaking any rules

> by having lots and lots of identical tables?  As you can

> probably tell, I don't have much experience doing the initial

> table design.

>

> TIA,

>

> -Ramon

>

>

>

> "Jan Gelbrich" <j_gelbrich_at_westfalen-blatt.de> wrote in message

news:<bhfdse$4no5$1_at_ID-152732.news.uni-berlin.de>...


> > 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