Další architektury ovladačů

Některé ovladače ODBC nejsou striktně v souladu s architekturou popsanou výše. Důvodem může být to, že ovladače plní jiné povinnosti než tradiční ovladač ODBC nebo nejsou ovladači v normálním smyslu.

Ovladač jako střední komponenta

Ovladač ODBC se může nacházet mezi Správcem ovladačů a jedním nebo více jinými ovladači ODBC. Když ovladač uprostřed dokáže pracovat s více zdroji dat, funguje jako dispečer volání ODBC (nebo správně přeložená volání) do jiných modulů, které skutečně přistupují ke zdrojům dat. V této architektuře přejímá ovladač uprostřed část role správce ovladačů.

Dalším příkladem tohoto typu ovladače je špionážní program pro rozhraní ODBC, který zachycuje a kopíruje funkce ODBC, které se odesílají mezi Správcem ovladačů a ovladačem. Tuto vrstvu lze použít k emulaci ovladače nebo aplikace. Ve Správci ovladačů se zdá, že vrstva je ovladačem; pro ovladač se zdá, že vrstva je Správcem ovladačů.

Heterogenní slučovací moduly

Některé ovladače ODBC jsou založené na dotazovacím stroji pro provádění heterogenních spojení. V jedné architektuře heterogenního modulu spojení (viz následující obrázek) se ovladač aplikaci jeví jako ovladač, ale jinému instance Správce Ovladačů připadá jako aplikace. Tento ovladač zpracovává heterogenní spojení z aplikace voláním samostatných příkazů SQL v ovladačích pro každou připojenou databázi.

Tato architektura poskytuje společné rozhraní pro přístup k datům z různých databází. Může používat běžný způsob načítání metadat, jako jsou například informace o speciálních sloupcích (identifikátory řádků), a může volat běžné funkce katalogu k načtení informací ze slovníku dat. Voláním funkce ODBC SQLStatistics může aplikace například načíst informace o indexech tabulek, které mají být spojeny, i když jsou tabulky ve dvou samostatných databázích. Procesor dotazů se nemusí starat o to, jak databáze ukládají metadata.

Aplikace má také standardní přístup k datovým typům. ROZHRANÍ ODBC definuje běžné datové typy SQL, na které jsou mapovány datové typy specifické pro DBMS. Aplikace může volat SQLGetTypeInfo k načtení informací o datových typech v různých databázích.

Když aplikace vygeneruje heterogenní příkaz join, procesor dotazů v této architektuře analyzuje příkaz SQL a potom vygeneruje samostatné příkazy SQL pro každou databázi, která se připojí. Pomocí metadat o každém ovladači může procesor dotazů určit nejúčinnější, inteligentní spojení. Pokud například příkaz spojí dvě tabulky v jedné databázi s jednou tabulkou v jiné databázi, procesor dotazů může tyto dvě tabulky v jedné databázi spojit před spojením výsledku s tabulkou z druhé databáze.

ODBC na serveru

Ovladače ODBC lze nainstalovat na server, aby je mohly používat aplikace na libovolné řadě klientských počítačů. V této architektuře (viz následující obrázek) se na každém klientovi nainstaluje Správce ovladačů a jeden ovladač ODBC a na serveru se nainstaluje další správce ovladačů a řada ovladačů ODBC. To umožňuje každému klientovi přístup k různým používaným a udržovaným ovladačům na serveru.

Jednou z výhod této architektury je efektivní údržba a konfigurace softwaru. Ovladače je potřeba aktualizovat pouze na jednom místě: na serveru. Pomocí systémových zdrojů dat lze zdroje dat definovat na serveru pro použití všemi klienty. Zdroje dat nemusí být definovány v klientovi. Sdružování připojení lze použít ke zjednodušení procesu, pomocí kterého se klienti připojují ke zdrojům dat.

Ovladač na klientovi je obvykle velmi malý ovladač, který přenese volání Správce ovladačů na server. Jeho nároky mohou být výrazně menší než plně funkční ovladače ODBC na serveru. V této architektuře je možné uvolnit klientské prostředky, pokud má server větší výpočetní výkon. Kromě toho je možné zvýšit efektivitu a zabezpečení celého systému instalací záložních serverů a výkonem vyrovnávání zatížení za účelem optimalizace využití serveru.