Tom,
On 4/11/06, Tom M. [email protected] wrote:
Funny, can’t see the forest for the trees!
Question: Why store a yearly salary as a per degenerate
hour rate rather than an actual salary, whatever that
is and calculate hourly rates on-the-fly with floats?
Mainly because payroll people seem to regard actual salary as an
imaginary
number, and hourly rate the only one that really counts! Bear in mind
that
for hourly rate employees you need to work with hourly rates anyway, and
they are often specified by law to 4dp, so payroll people would rather
have
just one way of calculating pay (hourly rate * hours * percent of
ordinary
rate).
I understand why you’d need to convert to that once in
a while for time off, etc. I also understand the need
to avoid floats for many purposes due to rounding and
accuracy problems.
But, you could calculate the per hourly rate with floats
on the fly and store the calculated total?
That would certainly work, although the number of times you would have
to do
that calculation is higher than you might think. You rarely get nice
numbers
to work with either, for example someone’s salary may be $62,314 and
their
standard weekly hours 37.5, and their overtime rate is 125% of their
ordinary hourly rate (and yes, salaried employees sometimes do get
overtime,
or other hourly rate penalties).
For instance, let’s take your example and calculate a
In the salary model you could use STI for
all the different salary types (hourly,
weekly, bi-weekly, semi-monthly, monthly,
yearly, etc.) and have methods to calculate
interim payments from the actual salary,
on the fly.
–
– Tom M.
That certainly works if Rails is the only application using the data,
but
when you are webifying a legacy application (or even just moving an
existing
web app to Rails) you don’t always have the luxury of working with that
sort
of object model.
At the end of the day I’m just glad that the solution is only 3 lines of
code per affected column, with a couple of extra requires lines per
model.
In many other languages that would have been far harder to handle! It
also
allows me to concentrate on what I really need to work on and not worry
about where floats might have introduced calculation errors into my
code, so
I will probably use this for my personal financial apps, unless that
money
data type has some compelling functionality I really need (I will be
looking
into it).
BTW, I don’t have my Ruby/Rails books here, what is STI?