in reply to What Do Monks Think of SQL Query Builders?

Opportunity is missed by most people because it is dressed in overalls and looks like work.
-- attributed to Thomas A. Edison

I'd definitely recommend to sit down and have a look at SQL. For three reasons:

1) Abstractions have a tendency to be leaky. There's a good chance that at some point you're forced to look at the pre-built SQL anyway because something really odd is happening.

2) Proper written SQL can save your application and your database a lot of time. Putting the data selection and aggregation logic logic into the SQL can drastically reduce the amount of memory, disk I/O and network bandwidth required.

3) SQL is extremely good at hiding parallel execution. Something that might be difficult to express in Perl can be extremely simple (and also efficient) in SQL. Put differently: "If all you have is a hammer, every problem looks like a nail." (Coming from the other direction: I've seen database admins performing arithmetic calculations and string manipulation in SQL - it worked but it definitely was not pretty.)

Maybe you still decide to stick with an SQL builder because that's really all what's needed. That's alright. But SQL is pretty fantastic and well worth a look.

  • Comment on Re: What Do Monks Think of SQL Query Builders?

Replies are listed 'Best First'.
Re^2: What Do Monks Think of SQL Query Builders?
by nysus (Parson) on Feb 08, 2017 at 21:49 UTC

    Yes, I totally get that. SQL is very powerful. But since it's not something I need to work with every day, I grow tired of learning it one year and then relearning it the next. I could spend a week learning it inside and out, I suppose. But my other thought is that since I'm not a professional db programmer, maybe building on someone else's work is good enough for me. And I'm particularly intrigued by the idea of being able to write a simple line of Perl code and have all the heavy lifting done for me.

    Perhaps if I saw an example of how to properly use SQL queries with a Perl application I would at least have something to draw from. All I really know are snippets from SQL tutorials. I guess it feels little overwhelming to figure out best practices without seeing how it should be done.

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
    $nysus = $PM . ' ' . $MCF;
    Click here if you love Perl Monks

[reply]
      "I grow tired of learning it one year and then relearning it the next."

      You would feel the same about Perl if you treated it the same way.

      "And I'm particularly intrigued by the idea of being able to write a simple line of Perl code and have all the heavy lifting done for me."

      Generating SQL is not heavy lifting. Generating a robust schema that modules your entities and their relationships is the key here, and there is no substitution for learning this.

      Go get some education! Search for "Intro to SQL: Querying and managing data" over at Kahn.

[reply]

        I do kind of feel the same way about Perl. However, I've used it much more frequently than SQL. But I do find that it gets easier and easier to get back on the Perl horse each time I come back to it. I love using it.

        I've read a book or two or three or four (ok, not cover to cover, admittedly) over the years on databases. For the kind of basic applications I write and with the dabbling I've done over the years, and with some help of existing websites, I can probably get by with the knowledge I have retained and create a decent schema; probably not the ideal one, but one that works good enough. Writing a perfect one can only come with lots and lots of practice.

        Unfortunately, I have only limited time. So I'm just looking for some advice and learn from far more experienced programmers to help me to avoid unnecessary pain. I've found PerlMonks to be very beneficial in that respect. For example, I first learned about Moose last year here on PerlMonks and I am blown away by it. I love programming with it. So I greatly appreciate hearing these kinds of thoughts on best way to implement SQL. It all gives me food for thought. Thanks.

        $PM = "Perl Monk's";
        $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
        $nysus = $PM . ' ' . $MCF;
        Click here if you love Perl Monks

[reply]

In Section Seekers of Perl Wisdom