Другие архитектуры драйверов
Некоторые драйверы ODBC не соответствуют архитектуре, описанной ранее. Это может быть связано с тем, что водители выполняют обязанности, отличные от традиционных драйверов ODBC, или не являются водителями в нормальном смысле.
Драйвер как средний компонент
Драйвер ODBC может находиться между диспетчером драйверов и одним или несколькими другими драйверами ODBC. Если драйвер в середине способен работать с несколькими источниками данных, он выступает в качестве диспетчера вызовов ODBC (или соответствующим образом переведенных вызовов) к другим модулям, которые фактически обращаются к источникам данных. В этой архитектуре драйвер в середине принимает некоторые роли диспетчера драйверов.
Другим примером этого рода драйвера является шпионская программа ДЛЯ ODBC, которая перехватывает и копирует функции ODBC, отправляемые между диспетчером драйверов и драйвером. Этот уровень можно использовать для эмуляции драйвера или приложения. В диспетчере драйверов уровень, как представляется, драйвер; в драйвере уровень, как представляется, является диспетчером драйверов.
Разнородные подсистемы соединения
Некоторые драйверы ODBC основаны на обработчике запросов для выполнения разнородных соединений. В одной архитектуре подсистемы разнородного соединения (см. следующую иллюстрацию), драйвер отображается в приложении как драйвер, но появляется в другом экземпляре диспетчера драйверов в качестве приложения. Этот драйвер обрабатывает разнородное соединение из приложения путем вызова отдельных инструкций SQL в драйверах для каждой присоединенной базы данных.
Эта архитектура предоставляет общий интерфейс для приложения для доступа к данным из разных баз данных. Он может использовать общий способ получения метаданных, таких как сведения о специальных столбцах (идентификаторах строк), и он может вызывать общие функции каталога для получения сведений словаря данных. Например, вызывая функцию ODBC SQLStatistics, приложение может получить сведения об индексах, присоединенных к таблицам, даже если таблицы находятся в двух отдельных базах данных. Обработчик запросов не должен беспокоиться о том, как базы данных хранят метаданные.
Приложение также имеет стандартный доступ к типам данных. ODBC определяет общие типы данных SQL, с которыми сопоставляются типы данных, зависящие от СУБД. Приложение может вызывать SQLGetTypeInfo для получения сведений о типах данных в разных базах данных.
Когда приложение создает неоднородную инструкцию соединения, обработчик запросов в этой архитектуре анализирует инструкцию SQL, а затем создает отдельные инструкции SQL для каждой базы данных для присоединения. Используя метаданные о каждом драйвере, обработчик запросов может определить наиболее эффективное интеллектуальное соединение. Например, если инструкция присоединяет две таблицы к одной базе данных с одной таблицей в другой базе данных, обработчик запросов может присоединиться к двум таблицам в одной базе данных перед присоединением результата к таблице из другой базы данных.
ODBC на сервере
Драйверы ODBC можно установить на сервере, чтобы их можно было использовать приложениями на любом из клиентских компьютеров. В этой архитектуре (см. следующую иллюстрацию), диспетчер драйверов и один драйвер ODBC устанавливаются на каждом клиенте, а другой диспетчер драйверов и ряд драйверов ODBC устанавливаются на сервере. Это позволяет каждому клиенту получить доступ к различным драйверам, используемым и поддерживаемым на сервере.
Одним из преимуществ этой архитектуры является эффективное обслуживание и настройка программного обеспечения. Драйверы должны обновляться только в одном месте: на сервере. С помощью системных источников данных источники данных можно определить на сервере для использования всеми клиентами. Источники данных не должны быть определены на клиенте. Подключение пул можно использовать для упрощения процесса подключения клиентов к источникам данных.
Драйвер на клиенте обычно является очень небольшим драйвером, который передает вызов диспетчера драйверов серверу. Его объем может быть значительно меньше, чем полнофункциональный драйвер ODBC на сервере. В этой архитектуре клиентские ресурсы можно освободить, если сервер имеет больше вычислительной мощности. Кроме того, эффективность и безопасность всей системы можно повысить, установив резервные серверы и выполняя балансировку нагрузки для оптимизации использования сервера.