O ODBC é a resposta?

Antes de se aprofundar na questão da interoperabilidade, considere a seguinte pergunta: o aplicativo deve usar ODBC? Esta pode parecer uma pergunta estranha de se fazer em um guia para ODBC, mas é, na verdade, uma pergunta legítima. O ODBC não foi projetado para substituir completamente as APIs de banco de dados nativas, nem foi projetado para fornecer acesso ao banco de dados em todas as circunstâncias. Ele foi projetado para fornecer uma interface comum para bancos de dados e foi destinado a liberar programadores de aplicativos de ter que aprender sobre e manter links para vários bancos de dados.

Aplicativos personalizados são os principais candidatos para APIs de banco de dados nativas. O principal motivo é que os aplicativos personalizados geralmente funcionam com um único DBMS e não precisam ser interoperáveis. As APIs de banco de dados nativas podem fazer um trabalho melhor do que o ODBC de expor as capacidades de um DBMS específico e podem expor capacidades não expostas pelo ODBC. Além disso, como os desenvolvedores de aplicativos personalizados geralmente estão familiarizados com a API de banco de dados nativa para seus DBMS, há poucos motivos para aprender ODBC. No entanto, é interessante observar que, para alguns DBMSs, ODBC é a API de banco de dados nativa.

Então, quais são os aplicativos candidatos ao ODBC? Os melhores candidatos são aplicativos que funcionam com mais de um DBMS. Isso inclui praticamente todos os aplicativos genéricos e verticais. Ele também inclui uma série de aplicativos personalizados. Por exemplo, aplicativos personalizados que usam vários DBMSs diferentes são muito mais fáceis e limpos de gravar com ODBC do que com várias APIs nativas. E aplicativos personalizados gravados com ODBC são muito mais fáceis de migrar à medida que uma empresa se move de um DBMS para outro ou implanta o mesmo aplicativo em DBMSs diferentes.