Re^2: Fetch Data from MySQL

[Corion]

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.

[aaron_baugher]

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.

[anu2011]

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.

[runrig]

By looking at these problems, I am not sure whether Perl with MySQL is a right way to go.

Do not misinterpret the above discussion as there being "problems" with Perl and MySQL. Nobody said there were problems with Perl and MySQL. The two work perfectly well together. The argument you see above is about using ORM's (e.g. DBIx::Class, Rose::DB::Object) which is an entirely separate issue which sparks arguments/debates/discussions like the one above. Start with Perl, DBI, and SQL, then maybe start looking at ORM's if you feel like it, try'em out, and use them if you feel that they're right for you.

[aaron_baugher]

You certainly can use Perl; people were using Perl and DBI to talk to SQL databases long before PHP and its MySQL procedures even existed. It's really pretty simple. It sounds like all you need is a new programmer.

[tospo]

It is defintely the right way to go. As the above post says, ignore our discussion about DBIC vs bare-bones DBI and just take a look at the many examples for Perl/database interactions on the web. If you know SQL, you will find that Perl DBI will simply give you a way of issuing those SQL queries from within a Perl script and capturing the results for further processing, which is what you need. It may sound more tricky than it actually is.