in reply to Applying logical operators in either complex SQL xor hashes?

Push as much complexity onto the database as possible. The reason is that the performance of a database has been optimized like crazy, so the more you can get the database to handle, the better.

Alex / talexb / Toronto

For a long time, I had a link in my .sig going to Groklaw. I heard that as of December 2024, this link is dead. Still, thanks to PJ for all your work, we owe you so much. RIP Groklaw -- 2003 to 2013.

  • Comment on Re: Applying logical operators in either complex SQL xor hashes?

Replies are listed 'Best First'.
Re^2: Applying logical operators in either complex SQL xor hashes?
by mldvx4 (Friar) on May 11, 2025 at 15:23 UTC

    Thanks, talexb, Marshall, and LanX!

    I now have the script concatenating as large a query string as needed by repeating parts from template strings. Then it pulls everything in from the database through a single prepare() and execute() pair. One of the hard parts was knowing to push the query bind values into two lists to be passed to DBI's execute() and along the way another hard part was getting visible error messages even with the help of the CGI::Carp module.

    Two bindvalue lists are often needed because when the final SQL query sometimes starts with a WITH clause, that has to be prepended to the query which means in turn that the bind values have to be at the start. So I use a separate list for the the normal bind values. Both get pushed and sometimes several tables are used at the same time so the push has to take that into account by repeating the same value: push(@bindvalues, ($value) x 3); then the two lists of bind values are combined for the execute() statements.

    The template which the Perl script uses to assemble the query is big on its own.

    Anyway, I now see a way forward with rest of the Perl script.