Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Sommige ODBC-stuurprogramma's voldoen niet strikt aan de architectuur die eerder is beschreven. Dit kan zijn omdat de stuurprogramma's andere taken uitvoeren dan die van een traditioneel ODBC-stuurprogramma, of niet stuurprogramma's zijn in de normale zin.
Stuurprogramma als middelste onderdeel
Het ODBC-stuurprogramma kan zich bevinden tussen stuurprogrammabeheer en een of meer andere ODBC-stuurprogramma's. Wanneer het stuurprogramma in het midden kan werken met meerdere gegevensbronnen, fungeert het als dispatcher van ODBC-aanroepen (of correct vertaalde aanroepen) naar andere modules die daadwerkelijk toegang hebben tot de gegevensbronnen. In deze architectuur neemt de driver in het midden een deel van de rol van een Driver Manager op zich.
Een ander voorbeeld van dit type stuurprogramma is een spionprogramma voor ODBC, dat ODBC-functies onderschept en kopieert die worden verzonden tussen Driver Manager en het stuurprogramma. Deze laag kan worden gebruikt om een stuurprogramma of een toepassing te emuleren. Voor de Stuurprogramma Beheerder lijkt de laag het stuurprogramma te zijn; voor het stuurprogramma lijkt de laag de Stuurprogramma Beheerder te zijn.
Heterogene join-engines
Sommige ODBC-stuurprogramma's zijn gebaseerd op een query-engine voor het uitvoeren van heterogene joins. In een architectuur van een heterogene join-engine (zie de volgende afbeelding), functioneert het stuurprogramma als stuurprogramma voor de toepassing, maar functioneert het als een toepassing voor een andere instantie van Driver Manager. Dit stuurprogramma verwerkt een heterogene join vanuit de toepassing door afzonderlijke SQL-instructies aan te roepen in stuurprogramma's voor elke gekoppelde database.
Deze architectuur biedt een algemene interface voor de toepassing voor toegang tot gegevens uit verschillende databases. Het kan een algemene manier gebruiken om metagegevens op te halen, zoals informatie over speciale kolommen (rij-id's) en kan algemene catalogusfuncties aanroepen om gegevenswoordenlijstgegevens op te halen. Door de ODBC-functie SQLStatistics aan te roepen, kan de toepassing bijvoorbeeld informatie ophalen over de indexen in de tabellen die moeten worden gekoppeld, zelfs als de tabellen zich in twee afzonderlijke databases bevinden. De queryprocessor hoeft zich geen zorgen te maken over hoe de metagegevens van de databases worden opgeslagen.
De toepassing heeft ook standaardtoegang tot gegevenstypen. ODBC definieert algemene SQL-gegevenstypen waaraan DBMS-specifieke gegevenstypen zijn toegewezen. Een toepassing kan SQLGetTypeInfo aanroepen om informatie over gegevenstypen in verschillende databases op te halen.
Wanneer de toepassing een heterogene join-instructie genereert, parseert de queryprocessor in deze architectuur de SQL-instructie en genereert vervolgens afzonderlijke SQL-instructies voor elke database die moet worden gekoppeld. Door metagegevens over elk stuurprogramma te gebruiken, kan de queryprocessor de meest efficiënte, intelligente join bepalen. Als de instructie bijvoorbeeld twee tabellen in de ene database met één tabel in een andere database samenvoegt, kan de queryprocessor de twee tabellen in de ene database samenvoegen voordat het resultaat wordt samengevoegd met de tabel uit de andere database.
ODBC op de server
ODBC-stuurprogramma's kunnen op een server worden geïnstalleerd, zodat ze kunnen worden gebruikt door toepassingen op een van de clientcomputers. In deze architectuur (zie de volgende afbeelding), worden stuurprogrammabeheer en één ODBC-stuurprogramma op elke client geïnstalleerd en worden er een andere Driver Manager en een reeks ODBC-stuurprogramma's geïnstalleerd op de server. Hierdoor heeft elke client toegang tot verschillende stuurprogramma's die op de server worden gebruikt en onderhouden.
Een voordeel van deze architectuur is efficiënt softwareonderhoud en -configuratie. Stuurprogramma's hoeven slechts op één plaats te worden bijgewerkt: op de server. Door systeemgegevensbronnen te gebruiken, kunnen gegevensbronnen op de server worden gedefinieerd voor gebruik door alle clients. De gegevensbronnen hoeven niet op de client te worden gedefinieerd. Verbindingspooling kan worden gebruikt om het proces te stroomlijnen waarmee clients verbinding maken met gegevensbronnen.
Het stuurprogramma op de client is meestal een zeer klein stuurprogramma waarmee de Driver Manager-aanroep naar de server wordt overgedragen. De footprint kan aanzienlijk kleiner zijn dan de volledig functionele ODBC-drivers op de server. In deze architectuur kunnen clientresources worden vrijgemaakt als de server meer rekenkracht heeft. Bovendien kan de efficiëntie en beveiliging van het hele systeem worden verbeterd door back-upservers te installeren en taakverdeling uit te voeren om het servergebruik te optimaliseren.