in reply to Help prevent a ModPerl application from replacement by Java

You might want to give a second thought whether you should use Class::DBI. Even with language like Java (which is famous for its layers of abstration), the new trend of thought is to move away from "too much abstraction and temp object".

I have observed many Java applications, and many of us are moving away from the traditional DAO/DCO model. The level of abstraction of Class::DBI is even a bit higher than Java's DAO/DCO.

Especially with a database SQL-sensitive like Oracle, Class::DBI is a performance hit. Oracle cares a lot how you form your query, and you really should not leave that to a generic tool like Class::DBI.

  • Comment on Re: Help prevent a ModPerl application from replacement by Java

Replies are listed 'Best First'.
Re^2: Help prevent a ModPerl application from replacement by Java
by monsieur_champs (Curate) on Aug 30, 2005 at 02:50 UTC

    The profiler data (posted with the original question) states this. But I'll have a hard and dull drawback on not using it: my column names and table names are not intuitive nor easy to guess. This would be a pain to write SQL to them. But it seems better than dropping Perl in favor of Java.

    My hope is not need to do this. Maybe someone have a good suggestion that allows my Perl to fly...

    -- monsieur_champs

[reply]

      Maybe it's just me, but I do think that (as soon as the database server allows that) all SQL should be in stored procedures. Snippets of SQL scattered throughout the Perl (or VB or C or Java or whatever you use) code are a major PITA as soon as you have to make some changes in the database schema. Plus this allows the server to store the execution plans which is even better than caching them.

      Jenda
      XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

[reply]

In Section Seekers of Perl Wisdom