O ODBC é a resposta?

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

Aplicativos personalizados são os principais candidatos para APIs de banco de dados nativos. 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 nativos podem fazer um trabalho melhor do que o ODBC de expor os recursos de um determinado DBMS e podem expor recursos não expostos pelo ODBC. Além disso, como os desenvolvedores de aplicativos personalizados geralmente estão familiarizados com a API de banco de dados nativo para seu DBMS, há poucos motivos para aprender o ODBC. No entanto, é interessante observar que, para alguns DBMSs, o ODBC é a API de banco de dados nativo.

Então, quais aplicações são candidatas para usar 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 vários aplicativos personalizados. Por exemplo, aplicativos personalizados que utilizam diferentes DBMSs são muito mais fáceis e limpos de se escrever com ODBC do que com várias APIs nativas. E os aplicativos personalizados escritos com ODBC são muito mais fáceis de migrar à medida que uma empresa passa de um DBMS para outro ou implanta o mesmo aplicativo em DBMSs diferentes.