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 daquelas 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 drivers ODBC. Quando o driver intermediário pode trabalhar com diversas fontes de dados, atua como expedidor de chamadas ODBC (ou chamadas convertidas adequadamente) para outros módulos que realmente acessam as fontes de dados. Nesta arquitetura, o driver intermediário assume parte da função de Gerenciador de Driver.

Outro exemplo desse tipo de driver é um programa espião para ODBC, que intercepta e copia funções ODBC 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; ao driver, a camada parece ser o Gerenciador de Driver.

Mecanismos de junção heterogêneos

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

Essa arquitetura fornece uma interface comum para o aplicativo acessar dados de diferentes bancos de dados. 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 maneira 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 consultas nessa arquitetura analisa a instrução SQL e gera instruções SQL separadas para cada banco de dados a ser unido. Usando metadados sobre cada driver, o processador de consultas pode determinar a junção mais eficiente e inteligente. 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 consultas poderá unir as duas tabelas em um banco de dados antes de unir o resultado com a 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 clientes. Nessa 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.

A manutenção e a configuração eficientes do software são uma vantagem dessa arquitetura. Os drivers só precisam ser atualizados em um local: 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 às fontes de dados.

Geralmente, o driver no cliente é um driver muito pequeno que transfere a chamada do Gerenciador de Driver para o servidor. Seu espaço ocupado pode ser significativamente menor do que os drivers ODBC totalmente funcionais no servidor. Nessa arquitetura, os recursos do cliente poderão ser liberados se o servidor tiver mais poder computacional. Além disso, a eficiência e a segurança de todo o sistema podem ser melhoradas com a instalação de servidores de backup e a realização de balanceamento de carga para otimizar o uso do servidor.