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

[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.

[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!

[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.

[edebill]

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).