Re: Application using PostgreSQL as a back end (experienced programmers please) - Mailing list pgsql-novice
| From | Bill Dika |
|---|---|
| Subject | Re: Application using PostgreSQL as a back end (experienced programmers please) |
| Date | |
| Msg-id | 50705a160511181944l1f7b0387w30ecebc0cdcd4351@mail.gmail.com Whole thread Raw |
| In response to | Re: Application using PostgreSQL as a back end (experienced programmers please) (Chris Browne <cbbrowne@acm.org>) |
| List | pgsql-novice |
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
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@acm.org> wrote:
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?
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
pgsql-novice by date: