Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • My job is reporting. So while most Perl programmers seem to be hurrying as fast as they can to keep from having to write SQL, I'm going the other way - I don't want the necessary bits of Perl to obscure the big chunks of SQL.

    When it makes sense, I'm happy to recommend an ORM. Most transactional applications fall in that boat. But when I see convoluted APIs to try to build complex SQL in Perl, I always am left thinking, "Why should I learn an API that is as complicated as SQL to get less capability than raw SQL already gives me?"

    Furthermore if you're working with databases, I really think that you need to learn SQL. Learn what a database is, and how it works. That is knowledge that will repay you time and time again.

    Incidentally at a previous job we found that an excellent interview question was to outline a simple real-world problem, and ask the candidates to design a database schema to handle it. An example would be to design a database for football teams to develop reports to help our boss play fantasy football. An example of a report would be which players scored the most touchdowns in 2005.

    We saw this as a litmus test for design skills. If you're building a CRUD application (we were), laying out your database is a large part of your application design. Whether or not you're accessing it through raw SQL (we weren't), there is a direct relationship between how the database is laid out and what is easy to do in the application. Being able to see and appreciate those relationships is an important skill.

    Plus virtually every solution had issues. Which gave us an opportunity to see how a person could evolve their design when problems were pointed out in it. Seeing that thinking process was invaluable.

    But if you've spent your entire programming career running away from learning what a database is and how to use it, how would you do on a problem like that? (And how much worse do you do on the real-world programming problems that this problem is meant to emulate?)