Otras arquitecturas de controlador

Algunos controladores ODBC no se ajustan estrictamente a la arquitectura descrita anteriormente. Esto puede deberse a que los controladores realizan tareas distintas de las de un controlador ODBC tradicional o no son controladores estrictamente.

Controlador como componente intermedio

El controlador ODBC puede residir entre el Administrador de controladores y uno o varios otros controladores ODBC. Cuando el controlador intermedio es capaz de trabajar con varios orígenes de datos, actúa como distribuidor de llamadas ODBC (o llamadas traducidas adecuadamente) a otros módulos que realmente acceden a los orígenes de datos. En esta arquitectura, el controlador intermedio está adoptando parte del rol de administrador de controladores.

Otro ejemplo de este tipo de controlador es un programa espía para ODBC, que intercepta y copia las funciones ODBC que se envían entre el Administrador de controladores y el controlador. Esta capa se puede usar para emular un controlador o una aplicación. En el Administrador de controladores, la capa parece ser el controlador; en el controlador, la capa parece ser el Administrador de controladores.

Motores de combinación heterogénea

Algunos controladores ODBC se basan en un motor de consultas para realizar combinaciones heterogéneas. En una arquitectura de un motor de combinación heterogénea (vea la siguiente ilustración), el controlador aparece en la aplicación como controlador, pero aparece en otra instancia del Administrador de controladores como una aplicación. Este controlador procesa una combinación heterogénea de la aplicación mediante una llamada a instrucciones SQL independientes en controladores para cada base de datos combinada.

Esta arquitectura proporciona una interfaz común para que la aplicación acceda a datos de diferentes bases de datos. Puede usar un método común de recuperar metadatos, como información sobre columnas especiales (identificadores de fila) y puede llamar a funciones de catálogo comunes para recuperar información del diccionario de datos. Al llamar a la función de ODBC SQLStatistics, por ejemplo, la aplicación puede recuperar información sobre los índices de las tablas que se van a combinar, incluso si las tablas están en dos bases de datos independientes. El procesador de consultas no tiene que preocuparse de cómo las bases de datos almacenan los metadatos.

La aplicación también tiene acceso estándar a los tipos de datos. ODBC define tipos de datos SQL comunes a los que se asignan los tipos de datos específicos de DBMS. Una aplicación puede llamar a SQLGetTypeInfo para recuperar información sobre los tipos de datos en distintas bases de datos.

Cuando la aplicación genera una instrucción de combinación heterogénea, el procesador de consultas de esta arquitectura analiza la instrucción SQL y, a continuación, genera instrucciones SQL independientes para cada base de datos que se va a combinar. Mediante el uso de metadatos sobre cada controlador, el procesador de consultas puede determinar la combinación inteligente más eficaz. Por ejemplo, si la instrucción combina dos tablas en una base de datos con una tabla en otra base de datos, el procesador de consultas puede combinar las dos tablas de una base de datos antes de combinar el resultado con la tabla de la otra base de datos.

ODBC en el servidor

Los controladores ODBC se pueden instalar en un servidor para que las aplicaciones puedan usarlos en cualquier serie de máquinas cliente. En esta arquitectura (vea la siguiente ilustración), se instala un administrador de controladores y un único controlador ODBC en cada cliente y otro administrador de controladores y una serie de controladores ODBC en el servidor. Esto permite que cada cliente acceda a una variedad de controladores que se usan y mantienen en el servidor.

Una ventaja de esta arquitectura es un mantenimiento y configuración de software eficientes. Los controladores solo deben actualizarse en un único lugar: en el servidor. Mediante el uso de orígenes de datos del sistema, todos los clientes pueden definir orígenes de datos en el servidor. No es necesario definir los orígenes de datos en el cliente. La agrupación de conexiones se puede usar para simplificar el proceso por el que los clientes se conectan a orígenes de datos.

El controlador del cliente suele ser un controlador muy pequeño que transfiere la llamada del Administrador de controladores al servidor. Su superficie puede ser significativamente menor que los controladores ODBC totalmente funcionales en el servidor. En esta arquitectura, los recursos de cliente se pueden liberar si el servidor tiene más potencia de proceso. Además, la eficiencia y la seguridad de todo el sistema se pueden mejorar instalando servidores de copia de seguridad y realizando un equilibrio de carga para optimizar el uso del servidor.