Re^2: Access to remote DB

DBD::ODBC is sometimes way slower than DBD::Oracle (at least when I used both some years ago), especially when a lot of data has to be transported. The extra layers (ODBC manager, Oracle ODBC driver) simply don't stand in your way when you use Oracle's API directly via DBD::Oracle.

Generally, I recommend to use try the native driver first, and only after that, fall back to DBD::ODBC, e.g. when the native DBD can't be compiled for some reason or when it lacks some important feature that is available via ODBC (e.g. Unicode support).

Regarding "getting things done on multiple databases": My last project that intensively used DBD::Oracle also used DBD::ODBC for MS SQL Server and DBD::Pg, and it got things done with all three databases. The big trick was not to (ab)use driver-specific functions and a tiny layer above DBI that took care of the little SQL dialect differences and some MS SQL Server annoyances. Adding support for DB2 was planned but not implemented, adding support for other relational databases, like MySQL or even SQLite, would have been possible.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re^2: Access to remote DB

Replies are listed 'Best First'.
Re^3: Access to remote DB by roboticus (Chancellor) on Sep 28, 2010 at 16:41 UTC
afoken: I didn't mean to imply that there would be problems getting things done in multiple databases using multiple DBD drivers. I simply meant that if I use DBD::ODBC, I can use it for nearly all of my databases, whereas DBD::Oracle works only on the Oracle databases... Generally, my philosophy has been to use ODBC everywhere I can, and only use other DBD drivers when needed. And I rarely need to use any other DBD driver. ...roboticus	[reply]
Re^4: Access to remote DB by gnieddu (Initiate) on Sep 29, 2010 at 16:29 UTC
Folks, thanks for your help Gianni	[reply]