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 que no son las de un controlador ODBC tradicional o no son controladores en el sentido normal.

Controlador como componente intermedio

El controlador ODBC puede residir entre el Administrador de controladores y uno o varios otros controladores ODBC. Cuando el controlador en el medio 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 acceden realmente a los orígenes de datos. En esta arquitectura, el controlador en el medio está tomando parte del rol de administrador de controladores.

Otro ejemplo de este tipo de controlador es un programa spy 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. Para el Administrador de controladores, la capa parece ser el controlador; para el controlador, la capa parece ser el Administrador de controladores.

Motores de combinación heterogéneos

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

Arquitectura de un motor de combinación heterogéneo

Esta arquitectura proporciona una interfaz común para que la aplicación acceda a datos de diferentes bases de datos. Puede usar una manera 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. Mediante una llamada a la función ODBC SQLStatistics, por ejemplo, la aplicación puede recuperar información sobre los índices de las tablas que se van a unir, incluso si las tablas están en dos bases de datos independientes. El procesador de consultas no tiene que preocuparse por cómo almacenan los metadatos las bases de datos.

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

Cuando la aplicación genera una instrucción de combinación heterogéneo, 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 unir. 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 une dos tablas de una base de datos con una tabla en otra base de datos, el procesador de consultas puede unir las dos tablas de una base de datos antes de unir 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 puedan ser utilizados por las aplicaciones en cualquiera de una serie de máquinas cliente. En esta arquitectura (vea la siguiente ilustración), se instalan un Administrador de controladores y un único controlador ODBC en cada cliente, y se instala otro Administrador de controladores y una serie de controladores ODBC en el servidor. Esto permite que cada cliente acceda a una variedad de controladores usados y mantenidos en el servidor.

Arquitectura de controladores ODBC en un servidor

Una ventaja de esta arquitectura es el mantenimiento y la configuración de software eficientes. Los controladores solo deben actualizarse en un solo lugar: en el servidor. Mediante el uso de orígenes de datos del sistema, los orígenes de datos se pueden definir en el servidor para que los usen todos los clientes. 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 los 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 capacidad de proceso. Además, la eficacia y la seguridad de todo el sistema se pueden mejorar mediante la instalación de servidores de copia de seguridad y el equilibrio de carga para optimizar el uso del servidor.