Про mysql ничего не скажу, ибо не пользовался никогда.
Что касается ORACLE, то личный опыт подсказывает использовать
напрямую вызовы OCI. Дабы сократить писанину, имеет
смысл над ними соорудить небольшую custom-надстройку.
Почему не советую использовать готовые надстройки?
unixODBC штука в целом неплохая и довольно надёжная,
но весьма ограниченная по возможностям (записать либо
прочитать с её помощью BLOB-поле я так и не сумел -
допускаю, впрочем, в данном случае проблемы с
/dev/hands ;-) ). А что касается прочих творений,
то здесь играют два фактора:
- при наложении глюков frontend'а на глюки собственно
ORACLE начинаются такие чудеса, что только держись. А
frontend приемлемой надёжности я видел ровно один - unixODBC.
- в Ораклячем саппорте часто работают редкие сволочи,
и если к ним приходит customer, использующий для доступа к
сервисам их продукта стороннюю прослойку, все баги и проблемы
они скопом, не разбираясь, валят на оную стороннюю прослойку.
Единственный шанс их дожать - притащить им *маленький*
кусок реального *своего* кода, обращающегося к СУБД
через OCI. Тут уж им просто деваться некуда.
Есть некая "родная" (самим Ораклом сделанная) надстройка над
OCI в виде набора C++-классов. Я не пользовался; может, оно
и ничего.