in reply to DBI inserts and what not

avoid simple $sth->do(). the statements aren't cached, and this will slow down the app ( esp. if called in a loop ).

use  $sth->prepare() and  $sth->execute. you can also ( and should ) use the  $sth->bind_param( :1, 'foo' ) (check your DBI driver for syntax) to bind the parameters for input (and use $sth->bind_col( 1, \$foo ) for quick output access.

DBI was designed for speed from the beginning (so says Tim Bunce), so use the features that are there.

Replies are listed 'Best First'.
RE: RE: DBI inserts and what not
by runrig (Abbot) on Sep 11, 2000 at 23:50 UTC
    I've never understood the point to 'bind_param()', unless you really need to tell the driver what datatype the binding needs to be. I've always passed the parameters in during execute(), and haven't had any trouble (yet).

    I usually DO use bind_columns() for the select statements, although this particular question was about an insert statement.

    Update: Regarding geektron's comment below, my only point was about using bind_param() explicitly as opposed to binding the parameters at execute time. I believe it does the same thing (please correct me if I'm wrong), and the only reason to use bind_param explicitly is to change the default bind_type.

    (7 years later)Update: Well, I've finally gotten around to needing bind_param...now that I'm using DBI with Sybase (it just doesn't seem to like the default bindings sometimes).

[reply]
      why would one use bind_param() and bind_cols()? speed. it might take a bit more programmer time, but it removes database transaction time - which is usually the bottleneck in scripts.

      also, using bind_cols() saves a bit of time. the variables get their value assignments from the binding, so you don't need to use things like while ( my ($foo, $bar, $baz ) = $sth->fetchrow() )

      UPDATE: i've double-checked some notes from a tutorial on Advanced DBI from Tim Bunce and re-consulted the Cheetah book (Programming the DBI), passing the values to $sth->execute( $foo, $bar ) on a statement prepared with placeholders explicitly calls bind_params, so there is little visible difference between explicity binding parameters ( that get into an SQL statement), but there is a visible difference for output columns ( that would use bind_col ).

      bind_param IS needed to force datatype selection. and bind_param_inout is necessary for inout parameters.

      using placeholders will ensure that bind_param is called anyway. one would save a check to see if the params were already bound by explicity binding them, and there may be ( this in speculation ) portability issues.

      explicit binding would save on maintainability also.

      and i still remember something about DB caching and DBI caching differences between explicit/implicit calls to bind_param, but i can't find the notes to back it up.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom