On 4/11/06, Tom M. email@example.com 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
number, and hourly rate the only one that really counts! Bear in mind
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
just one way of calculating pay (hourly rate * hours * percent of
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
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
that calculation is higher than you might think. You rarely get nice
to work with either, for example someone’s salary may be $62,314 and
standard weekly hours 37.5, and their overtime rate is 125% of their
ordinary hourly rate (and yes, salaried employees sometimes do get
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,
when you are webifying a legacy application (or even just moving an
web app to Rails) you don’t always have the luxury of working with that
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
In many other languages that would have been far harder to handle! It
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
I will probably use this for my personal financial apps, unless that
data type has some compelling functionality I really need (I will be
BTW, I don’t have my Ruby/Rails books here, what is STI?