ODBC é a resposta?

Antes de abordar a questão da interoperabilidade, considere a seguinte questão: A aplicação deve usar ODBC de todo? Isto pode parecer uma pergunta estranha de fazer num guia sobre ODBC, mas é, de facto, legítima. O ODBC não foi concebido para substituir completamente as APIs nativas de bases de dados, nem para fornecer acesso à base de dados em todas as circunstâncias. Foi concebido para fornecer uma interface comum a bases de dados e destinava-se a libertar programadores de aplicações de terem de aprender e manter ligações para múltiplas bases de dados.

Aplicações personalizadas são candidatas principais para APIs nativas de bases de dados. A principal razão é que as aplicações personalizadas muitas vezes funcionam com um único SGBD e não precisam ser interoperáveis. APIs nativas de bases de dados podem fazer um trabalho melhor do que o ODBC a expor as capacidades de um determinado SGBD e podem expor capacidades não expostas pelo ODBC. Além disso, como os desenvolvedores de aplicações personalizadas costumam estar familiarizados com a API nativa da base de dados para os seus SGBD, há pouca razão para aprender ODBC. No entanto, é interessante notar que, para alguns SGBD, o ODBC é a API nativa da base de dados.

Então, quais aplicações são candidatos ao ODBC? Os melhores candidatos são aplicações que funcionam com mais do que um SGBD. Isto inclui praticamente todas as aplicações genéricas e verticais. Inclui também várias aplicações personalizadas. Por exemplo, aplicações personalizadas que utilizam vários SGBDs diferentes são muito mais fáceis e limpas de escrever com ODBC do que com múltiplas APIs nativas. E aplicações personalizadas escritas com ODBC são muito mais fáceis de migrar à medida que uma empresa se move de um SGBD para outro ou implementa a mesma aplicação em diferentes SGBD.