Having used and still being a Sybase fan, I can comment on that part of this. DBD::Sybase was still at version .23 or something until about a week ago. It had few if any of the amenities that the DBI crowd expect or want. The Sybperl module is still the way to go for robust systems. The simple fact in that case is that the author of both, Michael Peppler doesn't have the time to pimp up the DBD version much so work has gotten done on it in spurts.

BTW, I still feel that under linux, his .23 version is better than the alternatives for accessing M$SQL 7 DBs. I'm going to be real happy with the 1.0 version once I beat the crud out of the .91 version I grabbed last week.

As to the second claim, "I have not seen any DBI::DBD modules for object-oriented databases. " I have to ask, how many NON-DBI modules for OODB have you seen? In this case, it just might be that OODB people don't cater to Perl people and we see little use for them. Saying you've never seen any "easy-to-use throckles" means nothing if you don't give an impression of how many "throckles" you've seen.

Putting that algebraicaly, the weight of a person's opinion of a comparitive ratio shall be scaled according to his knowledge of the denominator, not the numerator.

One post-note: metaperl wouldn't have put the "Two post-notes" section in...

As the the real topic, I think OODBs just sound better to PHBs. In most real world cases I've seen, they would have just slowed the process of getting up and going down to a crawl. Making them fine-grained, flexible, and efficient seems like it is nigh impossible. You can tune a RDBS at the DB, table, and code levels. Half the people in the world wrap the DB in a OOish level at the API anyway and press on from there, maintaining the ability to tinker with the OO stuff away from the outer layers of code without being tied to the vendors OOness. I wrap objects around groups of DBI calls and it is keeping me happy and employed. =)

--
$you = new YOU;
honk() if $you->love(perl)