Re^2: Class::DBI not intuitive

"And I think the difference between retrieve and retrieve_all should be obvious just by looking at the name."

itub's explanation was very lucid, and I just want to elaborate a little bit on the quoted comment of his.

Other than the obvious difference implicated by the naming, the real concern is performance. It would be quite unwise to do a retrieve_all, when you only care about couple of rows. Indeed the underlying data system might support batch fetch, for example Oracle, this provides the opportunity to fully utilize this and similar kind of functionalities, in the actual implementation, to gain the best performance.

Comment on Re^2: Class::DBI not intuitive

Replies are listed 'Best First'.
Re^3: Class::DBI not intuitive by ryantate (Friar) on Jul 27, 2004 at 21:18 UTC
"... this provides the opportunity to fully utilize this and similar kind of functionalities, in the actual implementation, to gain the best performance." Does anyone know if Class::DBI actually does this? (Uses optimal implementation-specific functionality, for example in Oracle?) I read perldoc Class::DBI and the explanation for retreive_all doesn't say whether it does so. One of the reasons I have avoided Class::DBI is I worry its SQL must be heavily suboptimal to facilitate operation on everything from SQLite to Oracle. I remember reading a comment on PM from someone who was monitoring Class::DBI SQL queries in real time and reported being mildly horrified (I have never been able to find the post).	[reply]
Re^4: Class::DBI not intuitive by drago99 (Sexton) on Jul 28, 2004 at 04:23 UTC
There is Class::DBI::Oracle which could be used also, in place of Class::DBI (it subclasses Class::DBI). If/where you find sub-optimal SQL in Class::DBI, simply replace it inside Class::DBI::Oracle. When you've made some nice improvements, send in a patch so the rest of us can benefit. Look at Class::DBI as a starting point rather than an ending point.	[reply]


more useful options
	PerlMonks