Re: Application using PostgreSQL as a back end (experienced programmers please)

Hi Chris:

Many thanks for your input. I've bookmarked your pages and will try your
program (my initial attempt to download it from sourceforge was
unsuccessful). I am a Canadian chartered accountant and we use Intuit
Profile at work. I have some familiarity with the complexities of applying
income tax rules and calculations and have created some spreadsheets to
calculate personal income taxes for limited situations.

I thought that I would use Postgres tables to store all the inputs in a tax
return (linked to forms) and use plpgsql or plpython functions to do the
various calculations. I was thinking of one large master function that
calculates the actual taxes and takes as input various other functions
calculating subtotals from each form etc. The master function would take
care of the calculation ordering. Each change in an input field would
trigger a recalculation of the input field's own supporting function(s) as
well as a recalculation of the master function. I was wondering how slow
this might be. I never intended to use a table field to store calculated
results, (I was under the impression that it was incorrect database design)
but you have given me something to think about. Also I think I need boolean
fields to store the many Yes/No answers on forms that impact on the
calculations.

I haven't used Postgres before so I'm not sure if what I want to do is
possible and/or advisable. I see that you are advising against calculating
inside of Postgres. What language would you suggest I use to create the
'calculation engine'? How can that language get the info from Postgres?
Would you recommend Python? Can Prolog be used with PostgreSQL? Do I assume
that you are recommending that I use Prolog for this type of project and
forget about Postgres? Is it a difficult program to learn?

I didn't know that income taxes was a 'holy grail' to linux enthusiasts. The
only reason I have been thinking of doing a program myself was that I
couldn't find anything on the internet regarding linux and Canadian income
taxes and secondly, I have some experience with the subject matter.

Thanks again for your info. Please keep in touch and let me know if I can be
of any assistance to you or any other linux enthusiast that you know of who
may be dealing with this matter.

Regards,
Bill Dika
London, Ontario Canada

On 11/15/05, Chris Browne <cbbrowne(at)acm(dot)org> wrote:
>
> Christopher Browne <cbbrowne(at)acm(dot)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(at)~S" "cbbrowne" "ntlug.org <http://ntlug.org>")
> http://www.ntlug.org/~cbbrowne/spreadsheets.html
> How does the guy who drives the snowplow get to work in the mornings?
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>