> Hi All,
>
> Thanks for the replies. We had similar doubts and that's why this was
> posted.
>
> Ours is a payroll application and this table stores the processed
> details of all months. In our design, there are user definable salary
> components. There can be 20 to 100 components typically (including
> statutory, intermediate components). Now there are 9 values attached
> to each component (original, Loss of pay, arrears, net value etc).
> So, in the worst case, there can be 900 values against each staff (I
> put 2000 to 3000 on the higher side). Table also contains few other
> fields.
>
> In our existing design, we store the info staff & component wise.
> There is no problem except that certain report takes lot of time (as
> info has to be unpacked every time). I feel the most natural way to
> store this info is, to store the complete data staff wise, but then
> you will have more columns.
>
> What we wanted to know is, when a Database system supports unlimited
> columns, are there any problems related to it?
>
> With regards,
> Niegil

still sounds like a lot of wasted space to me. Since not all staff has every
component, seems to me to be better to normalise the component list.
Make a table with component type. (20-100 records)
now make a table staff components - FK into staff table and FK into
component table.
now make a table for values with FK into component.
you can now retrieve components for each staff member with their component
description.
Alan

Alan