Altre architetture di driver

Alcuni driver ODBC non sono strettamente conformi all'architettura descritta in precedenza. Questo potrebbe essere dovuto al fatto che i driver svolgono funzioni diverse da quelle di un driver ODBC tradizionale o non sono driver nel senso normale del termine.

Driver come componente intermedio

Il driver ODBC può risiedere tra Gestione driver e uno o più driver ODBC. Quando il driver intermedio è in grado di lavorare con più origini dati, agisce come dispatcher di chiamate ODBC (o chiamate opportunamente tradotte) ad altri moduli che accedono effettivamente alle origini dati. In questa architettura, il driver centrale assume in parte il ruolo di Gestione 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 utilizzato per emulare un driver o un'applicazione. Per Gestione driver, il livello sembra essere il driver; per il driver, il livello sembra essere Gestione driver.

Moduli di unione eterogenee

Alcuni driver ODBC sono basati su un modulo di query per l'esecuzione di unioni eterogenee. In un'architettura di motore di unioni eterogenee (vedere l'illustrazione seguente), il driver appare all'applicazione come un driver, ma appare a un'altra istanza di Gestione driver come un'applicazione. Questo driver elabora un’unione eterogenea dall'applicazione richiamando istruzioni SQL separate nei driver per ogni database unito.

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

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

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

ODBC nel Server

I driver ODBC possono essere installati su un server in modo che possano essere utilizzati dalle applicazioni su una serie di computer client. In questa architettura (vedere l'illustrazione seguente), Gestione driver e un singolo driver ODBC sono installati su ogni client, mentre un altro Gestione driver e una serie di driver ODBC sono installati sul server. In questo modo, ogni client può accedere a una serie di driver utilizzati e gestiti dal 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. Utilizzando le origini dati di sistema, le origini dati possono essere definite sul server per essere utilizzate da tutti i client. Le origini dati non devono essere definite nel client. Il pooling delle connessioni può essere utilizzato per semplificare il processo di connessione dei client alle origini dati.

Il driver sul client è di solito un driver molto piccolo che trasferisce la chiamata di Gestione driver al server. Il suo footprint può essere notevolmente inferiore a quello dei driver ODBC completamente funzionanti sul server. In questa architettura, le risorse del client possono essere liberate se il server dispone di maggiore 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 dei server.