Udostępnij przez


Inne architektury sterowników

Niektóre sterowniki ODBC nie są ściśle zgodne z opisaną wcześniej architekturą. Może to być spowodowane tym, że kierowcy wykonują obowiązki inne niż tradycyjnego kierowcy ODBC lub nie są kierowcami w normalnym sensie.

Sterownik jako składnik środkowy

Sterownik ODBC może znajdować się między menedżerem sterowników a co najmniej jednym sterownikiem ODBC. Gdy sterownik pośredniczący potrafi działać z wieloma źródłami danych, pełni rolę dyspozytora wywołań ODBC (lub odpowiednio przetłumaczonych wywołań) do innych modułów, które faktycznie uzyskują dostęp do źródeł danych. W tej architekturze sterownik w środku przejmuje część roli Zarządcy sterowników.

Innym przykładem tego rodzaju sterownika jest program szpiegowski dla ODBC, który przechwytuje i kopiuje funkcje ODBC wysyłane między Menedżerem sterowników a sterownikiem. Ta warstwa może służyć do emulowania sterownika lub aplikacji. Dla Menedżera sterowników, warstwa wydaje się być sterownikiem; dla sterownika, warstwa wydaje się być Menedżerem sterowników.

Heterogeniczne silniki łączenia

Niektóre sterowniki ODBC są zbudowane na silniku zapytań do przeprowadzania sprzężeń heterogenicznych. W jednej architekturze aparatu sprzężenia heterogenicznego (patrz poniższa ilustracja), sterownik jest postrzegany przez aplikację jako sterownik, ale przez inne wystąpienie Menedżera sterowników jako aplikacja. Ten sterownik przetwarza heterogeniczne sprzężenia z aplikacji, wywołując oddzielne instrukcje SQL w sterownikach dla każdej dołączonej bazy danych.

Architektura heterogenicznego silnika sprzężenia

Ta architektura udostępnia wspólny interfejs dla aplikacji w celu uzyskiwania dostępu do danych z różnych baz danych. Może on używać wspólnego sposobu pobierania metadanych, takich jak informacje o specjalnych kolumnach (identyfikatorach wierszy) i może wywoływać typowe funkcje wykazu w celu pobrania informacji o słowniku danych. Wywołując funkcję ODBC SQLStatistics, na przykład aplikacja może pobrać informacje o indeksach w tabelach, które mają zostać połączone, nawet jeśli tabele znajdują się w dwóch oddzielnych bazach danych. Procesor zapytań nie musi martwić się o sposób przechowywania metadanych przez bazy danych.

Aplikacja ma również standardowy dostęp do typów danych. OdBC definiuje typowe typy danych SQL, do których są mapowane typy danych specyficznych dla systemu DBMS. Aplikacja może wywołać metodę SQLGetTypeInfo , aby pobrać informacje o typach danych w różnych bazach danych.

Gdy aplikacja generuje heterogeniczną instrukcję sprzężenia, procesor zapytań w tej architekturze analizuje instrukcję SQL, a następnie generuje oddzielne instrukcje SQL dla każdej bazy danych do sprzężenia. Korzystając z metadanych dotyczących każdego sterownika, procesor zapytań może określić najbardziej wydajne, inteligentne sprzężenia. Jeśli na przykład instrukcja łączy dwie tabele w jednej bazie danych z jedną tabelą w innej bazie danych, procesor zapytań może połączyć dwie tabele w jednej bazie danych przed dołączeniem wyniku do tabeli z drugiej bazy danych.

ODBC na serwerze

Sterowniki ODBC można zainstalować na serwerze, aby mogły być używane przez aplikacje na dowolnej serii maszyn klienckich. W tej architekturze (patrz poniższa ilustracja) na każdym kliencie jest instalowany menedżer sterowników i jeden sterownik ODBC, a na serwerze jest instalowany inny menedżer sterowników oraz szereg sterowników ODBC. Umożliwia to każdemu klientowi dostęp do różnych sterowników używanych i utrzymywanych na serwerze.

Architektura sterowników ODBC na serwerze

Jedną z zalet tej architektury jest wydajna konserwacja i konfiguracja oprogramowania. Sterowniki muszą być aktualizowane tylko w jednym miejscu: na serwerze. Przy użyciu systemowych źródeł danych źródła danych można zdefiniować na serwerze do użytku przez wszystkich klientów. Źródła danych nie muszą być zdefiniowane na kliencie. Buforowanie połączeń może służyć do usprawnienia procesu, za pomocą którego klienci łączą się ze źródłami danych.

Sterownik na kliencie jest zwykle bardzo małym sterownikiem, który przesyła wywołanie Menedżera sterowników do serwera. Jego rozmiar może być znacznie mniejszy niż w pełni funkcjonalne sterowniki ODBC działające na serwerze. W tej architekturze zasoby klienta można zwolnić, jeśli serwer ma większą moc obliczeniową. Ponadto wydajność i bezpieczeństwo całego systemu można zwiększyć, instalując serwery kopii zapasowych i wykonując równoważenie obciążenia w celu zoptymalizowania użycia serwera.