Since you don't know it yet you'll need to give yourself time to get up to speed. I suggest you pick up a copy of "Learning Perl" from O'Reilly and find some small jobs to do while you learn. When you're done with that proceed to "CGI Progamming with Perl," "Programming the Perl DBI" and "Network Programming with Perl." These last three contain critical information you'll need to build your application using the best Perl techniques.

-sam

We faced a similar decision in 1999. Our company made a strategic choice to write all products in perl because we wanted to compete by providing a 100% web-based solution.

We use Apache, ActiveState Perl, and MySQL 4.0 mostly for all our products today. Not to advertise, but you can read about what they do on my company's website or on my personal website for a little more technical description.

We found that most web-based tasks can be quick to respond and provide users with an easy to use interface written in Perl, HTML/CSS, DHTML and JavaScript is more than adequate. We collect and store all kinds of data for small to enterprise size organizations (Network Inventory, SNMP polling, Desktop Inventory, Syslogs/eventlogs/snmp traps, and trouble ticketing)

With that said, the volume of data can present some problems when the back-end is written in perl. Over time we have overcome some complicated issues such as polling 1000s of reports in 5 minutes, receive 1000s of syslog events, and operate a call center within 1 server which essentially is constantly reading/writing to the MySQL back-end.

We did play with postgres a few places along the way and found the perl interface to postgres to be less then desireable. I can't say if it has been improved or not since I looked at it last (Late 2002).

Based on our success, I can say that it can certainly be done in Perl. However, depending on what you are doing, its important to make sure (probably are) the appropriate modules out there before coding the project. Modules can save time and make you more nimble to add and enhance features.

Hope this helps.
Marc

We did play with postgres a few places along the way and found the perl interface to postgres to be less then desireable.

Are you referring to DBD::Pg or PL/Perl? If the latter, it's been overhauled in the recently released PostgreSQL 8.0. If the former can you say whether PHP's native PostgreSQL functions are likely to be better?

As I recall, we were using DBD:Pg. I can't say whether the PHP stuff works since we've only recently (within the last year) began including some PHP tools as part of our solutions. However, I appreciate the update and will definitely keep PL/Perl in mind when we revisit this! -Marc

I have written two nodes about the language of choice, and the second article sounds like your situation: a fairly straightforward application, so that suggests PHP.

Perl can be a hard language to learn. For me, it was easy, but with 15 years experience in coding in C and a decent grounding in Systems Design, I had a head start. And I'm still learning new stuff, like How to structure tests that span several modules, six plus years after discovering Perl.

Perl is a lot of fun. It depends I guess on how much of an intellectual challenge you or your company are up for. And only you can answer that question.

Update:Fixed typo 'gues son' -> 'guess on'.

Another consideration is having to do a specific task for which a particular language has excellent tools, and others don't. But since your job seems to revolve around databases, it doesn't play much of a role. All important modern languages have excellent database interfaces to all major databases.

I agree with Anonymous Monk. It really is in which language do the programmers feel most comfortable with. If they're comfortable with all then let them pick.

I'm sure I'm going to get downvoted for saying this, but my prefered language for any kind of DB to web work is PHP. Perl I prefer for most any other back end work. I'm just more comfortable with doing that stuff in PHP (and PHP's syntax for this stuff seems easier to me).

IMHO either will handle the task. The language is also not the only factor to consider. The database and the webserver should also be evaluated as well as how well they all interact. I haven't used PostgreSQL (mainly b/c we're stuck with MySQL and Oracle) so I can't comment on how well it plays with Perl or any other language.

Some semi-interesting links:
http://www.linuxgazette.com/issue67/nielsen.html
http://www.linuxgazette.com/issue69/nielsen.html

> It really is in which language 
> do the programmers feel most 
> comfortable with.
[download]


I do not agree here. Certain languages have certain advantages. A lot of programmers have a feeling about different languages. There are only a few studies about the effectiveness of different languages.
A good starting point to understand the differences is an article available online:
Lutz Prechelt. An empirical comparison of seven programming languages. IEEE Computer 33(10):23-29, October 2000. (http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprt_computer2000.pdf)
Regarding DB, you should also reflect some performance issues. There was a section "how fast is the DBI?" in the CPAN documentation. I cannot find it anymore. Must have been removed.
But I'd say it is not DBI itself you should point your finger if you have performance issues.

And also don't forget to index any columns that might benefit from it (basically anything used as a key). In the past I built a complete site with Apache 1.3, mod_perl, template toolkit and PostgreSQL (using DBI to interface). It was fast, but only after adding a reverse-proxy in front of the mod_perl server. The only downside was the tremendous amount of memory this setup used. Actually there was another downside as well: it took me some time to figure out the intricacies of mod_perl. If you don't even know Perl to begin with, then the learning curve will be much higher for you. There are alternatives to mod_perl (eg, SpeedyCGI) but I'm not familiar with them and so can't comment on that. Needless to say though, plain old CGI scripts can only go so far...

In case anyone was wondering, like me, what a reverse proxy is, or why implementing one would achieve dramatic performance improvements, here's a Definition of reverse proxy:

"Reverse Proxies

A reverse proxy is a gateway for servers, and enables one web server to provide content from another transparently. As with a standard proxy, a reverse proxy may serve to improve performance of the web by caching; this is a simple way to mirror a website. But the most common reason to run a reverse proxy is to enable controlled access from the Web at large to servers behind a firewall."

I might suggest that the fact that you made a database abstraction layer at all led to your benefits rather than the choice of C for that layer.

I suspect you would have realized similar benefits had you written the abstraction layer in Perl.

Like I said before, we have tried this before and Perl has some serious efficiency issues with respect to PostGres. When you start getting large data sets back it will simply crash. Also since we noticed that the current PostGres CPAN modules were buggy we decided that instead of re-writing them in PERL we would just go ahead and do it in C. Of course it all boils down to design preferences and what the Developers are comfortable with.

Perl exists as a built-in tool to postgreSQL, it's called pl/perl. See PL/Perl documentation from postgres website
It's simply that using DBI to interface postgres to perl is NOT the best way; but perl integrates extremely tightly and efficiently to postgres.

I've been thinking of using Perl with PostgreSQL recently for a proejct. Can you tell me why DBD::Pg is any less efficient than DBD::mysql?