Outras arquiteturas de driver

Alguns drivers ODBC não seguem estritamente a arquitetura descrita anteriormente. Isto pode dever-se ao facto de os condutores desempenharem funções diferentes das de um condutor ODBC tradicional, ou não serem condutores no sentido normal.

Driver como Componente Intermédio

O controlador ODBC pode residir entre o Gestor de Controladores e um ou mais outros controladores ODBC. Quando o driver do meio é capaz de trabalhar com múltiplas fontes de dados, atua como despachante de chamadas ODBC (ou chamadas devidamente traduzidas) para outros módulos que efetivamente acedem às fontes de dados. Nesta arquitetura, o driver do meio assume parte do papel de Driver Manager.

Outro exemplo deste tipo de controlador é um programa espião para ODBC, que interceta e copia funções ODBC enviadas entre o Gestor de Drivers e o driver. Esta camada pode ser usada para emular tanto um driver como uma aplicação. Para o Gestor de Controladores, a camada parece ser o controlador; para o controlador, a camada parece ser o Gestor de Controladores.

Motores de Junção Heterogéneos

Alguns drivers ODBC são construídos sobre um motor de consulta para realizar joins heterogéneos. Numa arquitetura de um motor de junção heterogénea (ver a ilustração seguinte), o driver aparece para a aplicação como um driver, mas para outra instância do Driver Manager aparece como uma aplicação. Este driver processa uma junção heterogénea da aplicação, chamando instruções SQL separadas em drivers para cada base de dados unida.

Esta arquitetura fornece uma interface comum para a aplicação aceder a dados de diferentes bases de dados. Pode usar uma forma 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ção do dicionário de dados. Ao chamar a função ODBC SQLStatistics, por exemplo, a aplicação pode obter informações sobre os índices nas tabelas a serem juntadas, mesmo que as tabelas estejam em duas bases de dados separadas. O processador de consultas não tem de se preocupar com a forma como as bases de dados armazenam os metadados.

A aplicação também tem acesso padrão aos tipos de dados. A ODBC define tipos de dados SQL comuns aos quais os tipos de dados específicos do SGBD são mapeados. Uma aplicação pode chamar SQLGetTypeInfo para obter informações sobre tipos de dados em diferentes bases de dados.

Quando a aplicação gera uma instrução de junção heterogénea, o processador de consultas nesta arquitetura analisa a instrução SQL e depois gera instruções SQL separadas para cada base de dados a juntar. Ao utilizar metadados sobre cada driver, o processador de consultas pode determinar a junção mais eficiente e inteligente. Por exemplo, se a instrução juntar duas tabelas numa base de dados com uma tabela noutra base de dados, o processador de consultas pode juntar as duas tabelas numa base de dados antes de juntar o resultado à tabela da outra base de dados.

ODBC no Servidor

Os drivers ODBC podem ser instalados num servidor para que possam ser usados por aplicações em qualquer uma das várias máquinas clientes. Nesta arquitetura (ver a ilustração seguinte), um Gestor de Drivers e um único driver ODBC estão instalados em cada cliente, e outro Driver Manager e uma série de drivers ODBC são instalados no servidor. Isto permite a cada cliente o acesso a uma variedade de drivers usados e mantidos no servidor.

Uma vantagem desta arquitetura é a manutenção e configuração eficientes do software. Os drivers só precisam de ser atualizados num só local: no servidor. Ao utilizar 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 de estar definidas no cliente. O pooling de ligações pode ser usado para simplificar o processo pelo qual os clientes se ligam às fontes de dados.

O driver no cliente é normalmente um driver muito pequeno que transfere a chamada do Driver Manager para o servidor. A sua pegada pode ser significativamente menor do que os drivers ODBC totalmente funcionais no servidor. Nesta arquitetura, os recursos do cliente podem ser libertados se o servidor tiver mais poder de computação. Além disso, a eficiência e segurança de todo o sistema podem ser melhoradas através da instalação de servidores de backup e da realização de balanceamento de carga para otimizar o uso dos servidores.