Altre architetture di driver

Alcuni driver ODBC non sono strettamente conformi all'architettura descritta in precedenza. Ciò potrebbe essere dovuto al fatto che i driver eseguono compiti diversi da quelli di un driver ODBC tradizionale o non sono driver nel senso normale.

Driver come componente intermedio

Il driver ODBC può risiedere tra il Gestore driver e uno o più altri driver ODBC. Quando il driver al centro è in grado di lavorare con più origini dati, funge da dispatcher di chiamate ODBC (o chiamate tradotte in modo appropriato) ad altri moduli che accedono effettivamente alle origini dati. In questa architettura, il driver al centro assume parte del ruolo di gestore dei driver.

Un altro esempio di questo tipo di driver è un programma spia per ODBC, che intercetta e copia le funzioni ODBC inviate tra Gestione driver e il driver. Questo livello può essere usato per emulare un driver o un'applicazione. Per il Driver Manager, il livello sembra essere il driver; per il driver, il livello sembra essere il Driver Manager.

Motori di 'Join' eterogenei

Alcuni driver ODBC sono basati su un motore di query per l'esecuzione di join eterogenei. In un'architettura di un motore di join eterogeneo (vedere la figura seguente), il driver si presenta all'applicazione come un driver ma a un'altra istanza del Driver Manager come un'applicazione. Questo driver elabora un join eterogeneo dall'applicazione chiamando istruzioni SQL separate nei driver per ogni database aggiunto.

Questa architettura fornisce un'interfaccia comune per l'applicazione per accedere ai dati da database diversi. Può usare un modo comune per recuperare i metadati, ad esempio informazioni sulle colonne speciali (identificatori di riga) e può chiamare funzioni di catalogo comuni per recuperare informazioni sul dizionario dati. Chiamando la funzione ODBC SQLStatistics, ad esempio, l'applicazione può recuperare informazioni sugli indici nelle tabelle da unire, anche se le tabelle si trovano in due database separati. Query Processor non deve preoccuparsi del modo in cui i database archiviano i metadati.

L'applicazione ha anche accesso standard ai tipi di dati. ODBC definisce tipi di dati SQL comuni a cui vengono mappati i tipi di dati specifici di DBMS. Un'applicazione può chiamare SQLGetTypeInfo per recuperare informazioni sui tipi di dati in database diversi.

Quando l'applicazione genera un'istruzione join eterogenea, Query Processor in questa architettura analizza l'istruzione SQL e quindi genera istruzioni SQL separate per ogni database da unire. Utilizzando i metadati relativi a ciascun driver, il processore delle query può determinare l'unione più efficiente e intelligente. Ad esempio, se l'istruzione unisce due tabelle in un database con una tabella in un altro database, Query Processor può unire le due tabelle in un database prima di unire il risultato con la tabella dall'altro database.

ODBC nel server

I driver ODBC possono essere installati in un server in modo che possano essere usati dalle applicazioni in una serie di computer client. In questa architettura (vedere la figura seguente), gestione driver e un singolo driver ODBC vengono installati in ogni client e un'altra gestione driver e una serie di driver ODBC vengono installati nel server. In questo modo, ogni client può accedere a un'ampia gamma di driver usati e gestiti nel server.

Uno dei vantaggi di questa architettura è la manutenzione e la configurazione del software efficienti. I driver devono essere aggiornati in un'unica posizione: nel server. Usando le origini dati di sistema, le origini dati possono essere definite nel server per l'uso da parte di tutti i client. Le origini dati non devono essere definite nel client. Il pool di connessioni può essere usato per semplificare il processo tramite cui i client si connettono alle origini dati.

Il driver nel client è in genere un driver molto piccolo che trasferisce la chiamata di Gestione driver al server. Il footprint può essere notevolmente inferiore rispetto ai driver ODBC completamente funzionanti nel server. In questa architettura, le risorse client possono essere liberate se il server ha più potenza di calcolo. Inoltre, l'efficienza e la sicurezza dell'intero sistema possono essere migliorate installando server di backup ed eseguendo il bilanciamento del carico per ottimizzare l'uso del server.