Ugh. Please don't recommend any of the object-relational mappers as a way around learning SQL. All ORMs I've seen so far allow you to avoid writing simple SQL statements, but horribly fail once your needs go beyond fetching single rows. Some ORMs allow you to define how to join tables together, but they all fail once your needs go towards more complex statements.

In addition, ORMs are the wrong way to think about your data. They make you think of aggregates over your data in terms of Perl loops instead of pushing the work down to the database. Also, they either force you to write a separate class representing a query result or think that all results you will ever fetch from the database correspond to a single row in one table. Neither approach makes much sense to me.

Thank you. I'm glad I'm not the only one who doesn't see the point of working so hard to abstract away the SQL. DBIC is recommended so often that I keep looking at it, but it just looks like extra work. Writing and handling SQL queries -- especially ones simple enough for an ORM to handle -- isn't really that difficult.

Thanks for your information. By looking at these problems, I am not sure whether Perl with MySQL is a right way to go. By looking at the commands available, I thought I can use Perl with MySQL in Linux environment. If users have problems using them, I may have to look for other avenues. I still want to dig little further before moving away. The application I am thinking about involves more data extraction and writing. I am not worried about reporting side, because reports are not a huge part of it. If someone has any experience, I meant positive experience using Perl in this type of an environment, please share your experience with me.