Christopher Browne <cbbrowne@acm.org> writes:
>> I expect the income tax program to be computationally intensive but
>> I also expect most of this computation to take place in PostgreSQL
>> and not the front end.
>
> I disagree, and I have some history with this variety of application
> ;-).
>
> My personal tax calculator is an application I wrote in Prolog. The
> "base data" is a surprisingly compact set of Prolog rules.
> <http://sourceforge.net/projects/prologtaxes/>
>
> What is really vital in the application is how you store the rules for
> expressing the interrelation between fields. What you're sure to need
> to do is to draw the data out in order to do the calculations. I'd
> fully expect you to have some sort of "calculation engine" where the
> calculations get done. This may seem surprising, but I really think
> it won't take place inside the database.
Actually, this merits a bit more explanation...
The thing that made Prolog desirable, to me, for this application, and
which seems to me to make the database engine likely unsuitable is the
whole issue of "ordering of calculations."
In Prolog, I didn't have to say *anything* about what order the
various tax rules needed to be applied in order to calculate the final
results.
You'll find that expressly applying the logic to do all of the
calculations in proper order will be one of the irritating parts of
the application.
Doing the calculations inside the database engine would mandate doing
some fancy SQL indeed in order to ensure that:
a) All calculations are done in the right order
b) You have all of the interim balances presented to you...
This is essentially the same problem as that which spreadsheets have
in determining the "graph" of dependancies of one cell against
another...
--
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://www.ntlug.org/~cbbrowne/spreadsheets.html
How does the guy who drives the snowplow get to work in the mornings?
