Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re: Re: Re: Re: Re: dbi style questions (code, discussion)

by edebill (Scribe)
on Jan 01, 2002 at 21:39 UTC ( [id://135526] : note . print w/replies, xml ) Need Help??


in reply to Re: Re: Re: Re: dbi style questions (code, discussion)
in thread dbi style questions (code, discussion)

If you use placeholders similar to this or like in the insert_hash() example

Yes, placeholders work, but I consider them worse than manually quoting what needs to be quoted. There's no benefit to doing a single prepare then feeding in parameters to the $sth when you only do a given query once, and Manually quoting the right values also acts as a reminder to think about them - and things like input validation.

I guess what I'm saying is that there's really a limit to what can be done profitably through automation, at least in this case.

  • Comment on Re: Re: Re: Re: Re: dbi style questions (code, discussion)

Replies are listed 'Best First'.
Re (tilly) 6: dbi style questions (code, discussion)
by tilly (Archbishop) on Jan 06, 2002 at 06:20 UTC
    How can you say that there is no benefit when you were just told the biggest benefit, that you don't have to synchronize information on the types of variables between your code and your database?

    Removing excess synchronization is always good IMO!

Re: Re: Re: Re: Re: Re: dbi style questions (code, discussion)
by runrig (Abbot) on Jan 02, 2002 at 00:18 UTC
    There's no benefit to doing a single prepare then feeding in parameters to the $sth when you only do a given query once...

    Ohh, that depends on the database. Some databases have their own SQL cache, so even if DBI's not caching your statement handles, the database might be caching your statement and won't have to parse it again, and placeholders help in that regard.

    Update: See this on the subject.

      It actually has to parse it in that case to compare the placeholders :-) The real win is when it can avoid passing it to the optimizer, because it already has an execution plan worked out.

      Our queries are simple enough that we actually turn down the SQL optimizer (for instance, we went for a long time with only 1 query that did a sub-select. Then I rewrote the query so it only needed a simple comparison.) This is actually recommended by IBM - they have docs on what optimization level to use for different things, and we fall squarely in the "turn it off, it's just wasting cycles" category.

      Part of the reason that DB interfaces (and databases themselves) are so hairy is that there are so many different usage cases, and they try to let you optimize for all of them. It's like having a Linux distro that tries to work well for everything from embedded devices (e.g. iPaq) to monster servers (e.g. Sun E10k).