Outras arquiteturas do driver

Alguns drivers ODBC não estão estritamente em conformidade com a arquitetura descrita anteriormente. Isso pode ocorrer porque os drivers executam tarefas diferentes das de um driver ODBC tradicional ou não são drivers no sentido normal.

Driver como componente intermediário

O driver ODBC pode residir entre o Gerenciador de Driver e um ou mais outros drivers ODBC. Quando o driver intermediário é capaz de trabalhar com várias fontes de dados, ele atua como um encaminhador de chamadas ODBC (ou chamadas traduzidas de forma apropriada) para outros módulos que realmente acessam as fontes de dados. Nessa arquitetura, o driver no meio está assumindo parte da função de um Gerenciador de Driver.

Outro exemplo desse tipo de driver é um programa espião para ODBC, que intercepta e copia funções ODBC que estão sendo enviadas entre o Gerenciador de Driver e o driver. Essa camada pode ser usada para emular um driver ou um aplicativo. Para o gerenciador de driver, a camada parece ser o driver; para o driver, a camada parece ser o gerenciador de driver.

Mecanismos de junção heterogênea

Alguns drivers ODBC são criados com base em um mecanismo de consulta para executar junções heterogêneas. Em uma arquitetura de um mecanismo de junção heterogêneo (veja a ilustração a seguir), o driver aparece para o aplicativo como um driver, mas aparece para outra instância do Gerenciador de Driver como um aplicativo. Esse driver processa uma junção heterogênea do aplicativo chamando instruções SQL separadas em drivers para cada banco de dados ingressado.

Essa arquitetura fornece uma interface comum para o aplicativo acessar dados de bancos de dados diferentes. Ele pode usar uma maneira comum de recuperar metadados, como informações sobre colunas especiais (identificadores de linha), e pode chamar funções de catálogo comuns para recuperar informações do dicionário de dados. Chamando a função ODBC SQLStatistics, por exemplo, o aplicativo pode recuperar informações sobre os índices nas tabelas a serem unidas, mesmo que as tabelas estejam em dois bancos de dados separados. O processador de consulta não precisa se preocupar com a forma como os bancos de dados armazenam metadados.

O aplicativo também tem acesso padrão aos tipos de dados. O ODBC define tipos de dados SQL comuns para os quais os tipos de dados específicos do DBMS são mapeados. Um aplicativo pode chamar SQLGetTypeInfo para recuperar informações sobre tipos de dados em bancos de dados diferentes.

Quando o aplicativo gera uma instrução de junção heterogênea, o processador de consulta nessa arquitetura analisa a instrução SQL e, em seguida, gera instruções SQL separadas para cada banco de dados a ser ingressado. Usando metadados sobre cada driver, o processador de consulta pode determinar a junção inteligente e mais eficiente. Por exemplo, se a instrução unir duas tabelas em um banco de dados com uma tabela em outro banco de dados, o processador de consulta poderá unir as duas tabelas em um banco de dados antes de unir o resultado à tabela do outro banco de dados.

ODBC no servidor

Os drivers ODBC podem ser instalados em um servidor para que possam ser usados por aplicativos em qualquer uma de uma série de computadores cliente. Nesta arquitetura (consulte a ilustração a seguir), um Gerenciador de Driver e um único driver ODBC são instalados em cada cliente, e outro Gerenciador de Driver e uma série de drivers ODBC são instalados no servidor. Isso permite que cada cliente acesse uma variedade de drivers usados e mantidos no servidor.

Uma vantagem dessa arquitetura é a manutenção e a configuração de software eficientes. Os drivers só precisam ser atualizados em um só lugar: no servidor. Usando fontes de dados do sistema, as fontes de dados podem ser definidas no servidor para uso por todos os clientes. As fontes de dados não precisam ser definidas no cliente. O pool de conexões pode ser usado para simplificar o processo pelo qual os clientes se conectam a fontes de dados.

O driver no cliente geralmente é um driver muito pequeno que transfere a chamada do Gerenciador de Driver para o servidor. Sua pegada pode ser muito menor do que a dos drivers ODBC, totalmente funcionais, no servidor. Nessa arquitetura, os recursos do cliente poderão ser liberados se o servidor tiver mais poder de computação. Além disso, a eficiência e a segurança de todo o sistema podem ser aprimoradas instalando servidores de backup e executando o balanceamento de carga para otimizar o uso do servidor.