Frequently, the preference is to program for an interface that a language's producer promotes, such as ADO, OLE/DB, or PERL:DBI—but those interfaces may have a lower layer, namely ODBC.
Alternatively, and also frequently, the preference is to program for an interface that a DBMS's producer promotes, such as Oracle OCI or DB Lib—but those interfaces have a higher or alternate layer, namely ODBC.
Because it can't do anything with objects and can't do anything without pointers, ODBC often needs some bridge or mediator to fit the tastes of the modern age. If we were to try to summarize what we think is the general attitude though, it's that ODBC is a solid and near-universal choice—albeit a second choice.
ODBC applications are usually faster than non-ODBC applications, despite attempts by interested parties to show otherwise. We believe that the commandment—Use ODBC—is in itself a good optimization tip. If you accept that at this point, then this chapter has been useful.