Другие архитектуры драйверов

Некоторые драйверы ODBC не соответствуют архитектуре, описанной ранее. Это может быть связано с тем, что водители выполняют обязанности, отличные от традиционных драйверов ODBC, или не являются водителями в нормальном смысле.

Драйвер как средний компонент

Драйвер ODBC может находиться между диспетчером драйверов и одним или несколькими другими драйверами ODBC. Если драйвер в середине способен работать с несколькими источниками данных, он выступает в качестве диспетчера вызовов ODBC (или соответствующим образом переведенных вызовов) к другим модулям, которые фактически обращаются к источникам данных. В этой архитектуре центральный драйвер берет на себя часть функций диспетчера драйверов.

Другим примером этого рода драйвера является шпионская программа ДЛЯ ODBC, которая перехватывает и копирует функции ODBC, отправляемые между диспетчером драйверов и драйвером. Этот уровень можно использовать для эмуляции драйвера или приложения. Для диспетчера драйверов слой выглядит как драйвер; для драйвера слой выглядит как диспетчер драйверов.

Гетерогенные механизмы соединения

Некоторые драйверы ODBC основаны на обработчике запросов для выполнения разнородных соединений. В одной архитектуре подсистемы разнородного соединения (см. следующую иллюстрацию), драйвер отображается в приложении как драйвер, но появляется в другом экземпляре диспетчера драйверов в качестве приложения. Этот драйвер обрабатывает разнородное соединение из приложения путем вызова отдельных инструкций SQL в драйверах для каждой присоединенной базы данных.

Эта архитектура предоставляет общий интерфейс для приложения для доступа к данным из разных баз данных. Он может использовать общий способ получения метаданных, таких как сведения о специальных столбцах (идентификаторах строк), и он может вызывать общие функции каталога для получения сведений словаря данных. Например, вызывая функцию ODBC SQLStatistics, приложение может получить сведения об индексах, присоединенных к таблицам, даже если таблицы находятся в двух отдельных базах данных. Обработчик запросов не должен беспокоиться о том, как базы данных хранят метаданные.

Приложение также имеет стандартный доступ к типам данных. ODBC определяет общие типы данных SQL, с которыми сопоставляются типы данных, зависящие от СУБД. Приложение может вызывать SQLGetTypeInfo для получения сведений о типах данных в разных базах данных.

Когда приложение создает неоднородную инструкцию соединения, обработчик запросов в этой архитектуре анализирует инструкцию SQL, а затем создает отдельные инструкции SQL для каждой базы данных для присоединения. Используя метаданные о каждом драйвере, обработчик запросов может определить наиболее эффективное интеллектуальное соединение. Например, если инструкция присоединяет две таблицы к одной базе данных с одной таблицей в другой базе данных, обработчик запросов может присоединиться к двум таблицам в одной базе данных перед присоединением результата к таблице из другой базы данных.

ODBC на сервере

Драйверы ODBC можно установить на сервере, чтобы их можно было использовать приложениями на любом из клиентских компьютеров. В этой архитектуре (см. следующую иллюстрацию), диспетчер драйверов и один драйвер ODBC устанавливаются на каждом клиенте, а другой диспетчер драйверов и ряд драйверов ODBC устанавливаются на сервере. Это позволяет каждому клиенту получить доступ к различным драйверам, используемым и поддерживаемым на сервере.

Одним из преимуществ этой архитектуры является эффективное обслуживание и настройка программного обеспечения. Драйверы должны обновляться только в одном месте: на сервере. С помощью системных источников данных источники данных можно определить на сервере для использования всеми клиентами. Источники данных не должны быть определены на клиенте. Пул подключений можно использовать для упрощения процесса, с помощью которого клиенты подключаются к источникам данных.

Драйвер на клиенте обычно является очень небольшим драйвером, который передает вызов диспетчера драйверов серверу. Его объем может быть значительно меньше, чем полнофункциональный драйвер ODBC на сервере. В этой архитектуре клиентские ресурсы можно освободить, если сервер имеет больше вычислительной мощности. Кроме того, эффективность и безопасность всей системы можно повысить, установив резервные серверы и выполняя балансировку нагрузки для оптимизации использования сервера.