laziness, impatience, and hubris | |
PerlMonks |
Re: plsql vs. perl vs. neither and API's (code)by wintrowski (Novice) |
on Jul 29, 2001 at 05:18 UTC ( [id://100631]=note: print w/replies, xml ) | Need Help?? |
At work, I am currently working on a project that is very very similar to that which you have described (although I am working with a much smaller database and probably much fewer users). I have two or three databases that I have to interface with, plus an internal e-mail system, a future employee hours accounting system, and God knows what else.
Because my project is not intended to be high-end where performance is going to be a major issue, I opted to hack things out in Perl, using CGI, DBI, and PostgreSQL. The advantages, I have found, to this approach are as follows.
I will admit that the Perl/DBI/CGI approach is not entirely perfect.
In your case, I honestly think that if you went the Perl/CGI/DBI route, in combination with mod_perl, you would have a pretty kick-ass system. It will be versatile, and can accommodate *any* changes or modifications that management want to throw at it. There is nothing that it can't do. Although I would say to you that if you are working with a huge database which will have a lot of processing done on it by many users, you may need to consider porting your system over to C at some point, depending on whether or not you notice serious performance deficiencies. I have never seen any bench marks to compare C-based CGI applications and mod_perl/CGI applications, so I am only speculating with regards to this performance issue. You may also want to look into PHP. I have never used it so I can't say as to how well suited it is to this task. If you want to discuss the Perl//CGI/DBI route further, mail me at wintrowski@yahoo.com and I can further relate to you my experiences. Wintrowski
In Section
Meditations
|
|