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

[edebill]

 # my sql statement.
my $sql = "INSERT INTO msg ( " . join (",\n", @keys) . ") " .
          "VALUES (" . join (",\n", @values) . ")";

I like it. Using join() this way simplifies the SQL generation a lot.

Unfortunately, there's no real help for manually $dbh->quote()ing values that need it - we use DB2 at work, and quoting a number gives a SQL error (grrrrrrrr). That's my #1 complaint about the thing.

We'll probably move to something between what your friend does, and the inline code. Generate the actual SQL in a module, but maintain control of it's execution inline - otherwise you're borked with transactions, and I hate passing $dbh's around all over the place.

[runrig]

Unfortunately, there's no real help for manually $dbh->quote()ing values that need it - we use DB2 at work, and quoting a number gives a SQL error (grrrrrrrr). That's my #1 complaint about the thing.

If you use placeholders similar to this or like in the insert_hash() example in the DBI documentation you might not have that problem. (Update: Or like in jarich's sql2 string above :) (Update: Yes, its usually the optimizer that doesn't have to parse your statement again if the database has a SQL cache, but placeholders are still worthwhile IMO, even on a database like MySQL)

[edebill]

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.

[runrig]

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.

[tilly]

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!