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 in senso normale.

Driver come componente intermedio

Il driver ODBC può trovarsi tra Gestione driver e uno o più altri driver ODBC. Quando il driver centrale è 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 Gestione driver.

Un altro esempio di questo tipo di driver è un programma spy 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. In Gestione driver il livello sembra essere il driver. per il driver, il livello sembra essere Gestione driver.

Motori di join eterogenei

Alcuni driver ODBC si basano 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 viene visualizzato nell'applicazione come driver, ma viene visualizzato in un'altra istanza di Gestione driver come applicazione. Questo driver elabora un join eterogeneo dall'applicazione chiamando istruzioni SQL nei driver per ogni database unito in join.

Architettura di un motore di join eterogeneo

Questa architettura fornisce un'interfaccia comune per l'applicazione per accedere ai dati da database diversi. Può usare un modo comune per recuperare metadati, ad esempio informazioni su colonne speciali (identificatori di riga), e può chiamare funzioni di catalogo comuni per recuperare informazioni sul dizionario dei dati. Chiamando la funzione ODBC SQLStatistics, ad esempio, l'applicazione può recuperare informazioni sugli indici nelle tabelle da unire in join, anche se si tratta di 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 i tipi SQL tipi di dati 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 di join eterogenea, Query Processor in questa architettura analizza l'istruzione SQL e quindi genera istruzioni SQL separate per ogni database da unire in join. Usando i metadati relativi a ogni driver, Query Processor può determinare il join intelligente più efficiente. Ad esempio, se l'istruzione unisce in join 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 alla tabella dell'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), vengono installati gestione driver e un singolo driver ODBC in ogni client e un altro Driver Manager 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.

Architettura di driver ODBC in un server

Uno dei vantaggi di questa architettura è la manutenzione e la configurazione efficienti del software. I driver devono essere aggiornati solo in un'unica posizione: nel server. Usando le origini dati di sistema, le origini dati possono essere definite nel server per l'utilizzo 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 con 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 ridotto 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 i server di backup ed eseguendo il bilanciamento del carico per ottimizzare l'uso del server.