Autres architectures de pilote

Certains pilotes ODBC ne sont pas strictement conformes à l’architecture décrite précédemment. Cela peut être dû au fait que les pilotes effectuent des tâches autres que celles d’un pilote ODBC traditionnel ou ne sont pas des pilotes dans le sens normal.

Pilote en tant que composant intermédiaire

Le pilote ODBC peut résider entre le Gestionnaire de pilotes et un ou plusieurs autres pilotes ODBC. Lorsque le pilote au milieu est capable d’utiliser plusieurs sources de données, il agit comme répartiteur d’appels ODBC (ou d’appels traduits de manière appropriée) vers d’autres modules qui accèdent réellement aux sources de données. Dans cette architecture, le pilote au milieu prend une partie du rôle d’un gestionnaire de pilotes.

Un autre exemple de ce type de pilote est un programme espion pour ODBC, qui intercepte et copie les fonctions ODBC envoyées entre le Gestionnaire de pilotes et le pilote. Cette couche peut être utilisée pour émuler un pilote ou une application. Dans le Gestionnaire de pilotes, la couche semble être le pilote ; pour le pilote, la couche semble être le Gestionnaire de pilotes.

Moteurs de jointure hétérogènes

Certains pilotes ODBC reposent sur un moteur de requête pour effectuer des jointures hétérogènes. Dans une architecture d’un moteur de jointure hétérogène (voir l’illustration suivante), le pilote apparaît à l’application en tant que pilote, mais il apparaît à une autre instance du Gestionnaire de pilotes en tant qu’application. Ce pilote traite une jointure hétérogène de l’application en appelant des instructions SQL distinctes dans les pilotes pour chaque base de données jointe.

Cette architecture fournit une interface commune pour que l’application accède aux données provenant de différentes bases de données. Il peut utiliser une méthode courante pour récupérer des métadonnées, telles que des informations sur des colonnes spéciales (identificateurs de lignes) et appeler des fonctions de catalogue courantes pour récupérer des informations de dictionnaire de données. En appelant la fonction ODBC SQLStatistics, par exemple, l’application peut récupérer des informations sur les index des tables à joindre, même si les tables se trouvent sur deux bases de données distinctes. Le processeur de requêtes n’a pas à vous soucier de la façon dont les bases de données stockent les métadonnées.

L’application dispose également d’un accès standard aux types de données. ODBC définit les types de données SQL courants auxquels les types de données spécifiques au SGBD sont mappés. Une application peut appeler SQLGetTypeInfo pour récupérer des informations sur les types de données sur différentes bases de données.

Lorsque l’application génère une instruction de jointure hétérogène, le processeur de requêtes de cette architecture analyse l’instruction SQL, puis génère des instructions SQL distinctes pour chaque base de données à joindre. En utilisant des métadonnées sur chaque pilote, le processeur de requêtes peut déterminer la jointure intelligente la plus efficace. Par exemple, si l’instruction joint deux tables sur une base de données avec une table sur une autre base de données, le processeur de requêtes peut joindre les deux tables sur la base de données avant de joindre le résultat à la table de l’autre base de données.

ODBC sur le serveur

Les pilotes ODBC peuvent être installés sur un serveur afin qu’ils puissent être utilisés par des applications sur une série de machines clientes. Dans cette architecture (voir l’illustration suivante), un gestionnaire de pilotes et un seul pilote ODBC sont installés sur chaque client, et un autre gestionnaire de pilotes ODBC et une série de pilotes ODBC sont installés sur le serveur. Cela permet à chaque client d’accéder à divers pilotes utilisés et gérés sur le serveur.

L’un des avantages de cette architecture est une maintenance et une configuration logicielle efficaces. Les pilotes ne doivent être mis à jour qu’à un seul emplacement : sur le serveur. À l’aide de sources de données système, les sources de données peuvent être définies sur le serveur pour une utilisation par tous les clients. Les sources de données ne doivent pas être définies sur le client. le regroupement Connecter ion peut être utilisé pour simplifier le processus par lequel les clients se connectent aux sources de données.

Le pilote sur le client est généralement un pilote très petit qui transfère l’appel du Gestionnaire de pilotes au serveur. Son encombrement peut être beaucoup plus petit que les pilotes ODBC entièrement fonctionnels sur le serveur. Dans cette architecture, les ressources clientes peuvent être libérées si le serveur a plus de puissance de calcul. En outre, l’efficacité et la sécurité de l’ensemble du système peuvent être améliorées en installant des serveurs de sauvegarde et en effectuant un équilibrage de charge pour optimiser l’utilisation du serveur.