Andere Treiberarchitekturen

Einige ODBC-Treiber entsprechen nicht unbedingt der zuvor beschriebenen Architektur. Dies kann daran liegen, dass die Treiber andere Aufgaben als die eines herkömmlichen ODBC-Treibers ausführen oder keine Treiber im normalen Sinne sind.

Treiber als mittlere Komponente

Der ODBC-Treiber kann sich zwischen dem Treiber-Manager und einem oder mehreren anderen ODBC-Treibern befinden. Wenn der Treiber in der Mitte in der Lage ist, mit mehreren Datenquellen zu arbeiten, fungiert er als Verteiler von ODBC-Aufrufen (oder entsprechend übersetzte Aufrufe) an andere Module, die tatsächlich auf die Datenquellen zugreifen. In dieser Architektur übernimmt der Treiber in der Mitte einige der Rollen eines Treiber-Managers.

Ein weiteres Beispiel für diese Art von Treiber ist ein Spionprogramm für ODBC, das ODBC-Funktionen abfangen und kopiert, die zwischen dem Treiber-Manager und dem Fahrer gesendet werden. Diese Ebene kann verwendet werden, um entweder einen Treiber oder eine Anwendung zu emulieren. Für den Treiber-Manager scheint die Ebene der Treiber zu sein; an den Treiber, scheint die Ebene der Treiber-Manager zu sein.

Heterogene Verknüpfungsmodule

Einige ODBC-Treiber basieren auf einem Abfragemodul zum Ausführen heterogener Verknüpfungen. In einer Architektur eines heterogenen Verknüpfungsmoduls (siehe folgende Abbildung) erscheint der Treiber der Anwendung als Treiber, erscheint aber einer anderen Instanz des Treiber-Managers als Anwendung. Dieser Treiber verarbeitet eine heterogene Verknüpfung aus der Anwendung, indem separate SQL-Anweisungen in Treibern für jede verknüpfte Datenbank aufgerufen werden.

Diese Architektur bietet eine gemeinsame Schnittstelle für die Anwendung für den Zugriff auf Daten aus verschiedenen Datenbanken. Sie kann eine gängige Methode zum Abrufen von Metadaten verwenden, z. B. Informationen zu speziellen Spalten (Zeilenbezeichnern), und sie kann allgemeine Katalogfunktionen aufrufen, um Datenwörterbuchinformationen abzurufen. Durch Aufrufen der ODBC-Funktion SQLStatistics kann die Anwendung beispielsweise Informationen zu den Indizes der tabellen abrufen, die verknüpft werden sollen, auch wenn sich die Tabellen in zwei separaten Datenbanken befinden. Der Abfrageprozessor muss sich keine Gedanken darüber machen, wie die Datenbanken Metadaten speichern.

Die Anwendung hat auch Standardzugriff auf Datentypen. ODBC definiert allgemeine SQL-Datentypen, denen DBMS-spezifische Datentypen zugeordnet sind. Eine Anwendung kann SQLGetTypeInfo aufrufen, um Informationen zu Datentypen in verschiedenen Datenbanken abzurufen.

Wenn die Anwendung eine heterogene Join-Anweisung generiert, analysiert der Abfrageprozessor in dieser Architektur die SQL-Anweisung und generiert dann separate SQL-Anweisungen für jede Datenbank, die verknüpft werden soll. Mithilfe von Metadaten zu jedem Treiber kann der Abfrageprozessor die effizienteste, intelligente Verknüpfung ermitteln. Wenn die Anweisung beispielsweise zwei Tabellen in einer Datenbank mit einer Tabelle in einer anderen Datenbank verknüpft, kann der Abfrageprozessor die beiden Tabellen in der datenbank verknüpfen, bevor das Ergebnis mit der Tabelle aus der anderen Datenbank verknüpft wird.

ODBC auf dem Server

ODBC-Treiber können auf einem Server installiert werden, sodass sie von Anwendungen auf einer Reihe von Clientcomputern verwendet werden können. In dieser Architektur (siehe folgende Abbildung), wird ein Treiber-Manager und ein einzelner ODBC-Treiber auf jedem Client installiert, und ein anderer Treiber-Manager und eine Reihe von ODBC-Treibern werden auf dem Server installiert. Auf diese Weise kann jeder Client auf eine Vielzahl von verwendeten Treibern zugreifen und Standard auf dem Server enthalten sein.

Ein Vorteil dieser Architektur ist effiziente Software Standard Tenance und Konfiguration. Treiber müssen nur an einer Zentralen Stelle aktualisiert werden: auf dem Server. Mithilfe von Systemdatenquellen können Datenquellen auf dem Server für die Verwendung durch alle Clients definiert werden. Die Datenquellen müssen nicht auf dem Client definiert werden. Verbinden ion-Pooling kann verwendet werden, um den Prozess zu optimieren, mit dem Clients eine Verbindung mit Datenquellen herstellen.

Der Treiber auf dem Client ist in der Regel ein sehr kleiner Treiber, der den Treiber-Manager-Aufruf an den Server überträgt. Der Speicherbedarf kann deutlich kleiner sein als die voll funktionsfähigen ODBC-Treiber auf dem Server. In dieser Architektur können Clientressourcen freigegeben werden, wenn der Server mehr Computerleistung hat. Darüber hinaus kann die Effizienz und Sicherheit des gesamten Systems verbessert werden, indem Sicherungsserver installiert und Lastenausgleich ausgeführt wird, um die Servernutzung zu optimieren.