Хроники DataBase Connectivity

Alexander S. Salieff

Спецвыпуск: Хакер, номер #052, стр. 052-020-4

ODBC на практике

Голая теория и употребление заумных аббревиатур - это, безусловно, хорошо. Но хотелось бы знать, как именно происходит ODBC-доступ клиентских приложений к базам данных. Выглядит это приблизительно так: каждый производитель РБД, заявляющий ODBC-поддержку под определенную операционную систему, предоставляет вместе со своим продуктом ODBC-драйвер. На самом деле, это даже никакой не драйвер (потому что он не является частью ядра операционной системы), а самая обычная динамическая библиотека (к примеру, DLL в MS Windows или SO в Linux), код которой будет исполняться в пространстве обычного пользовательского процесса. Эта библиотека обязана включать в себя набор стандартизованных ODBC-функций (и может включать дополнительные возможности), с точками вызова которых и будет линковаться приложение. Эти функции обязаны сохранять декларированные имена и аргументные типы, а их алгоритмы "знают", как добиться требуемого результата от базы данных конкретного производителя. Таким образом, не меняя исходного кода и алгоритма работы приложения, а просто линкуя его с различными ODBC-библиотеками, можно безболезненно мигрировать из одной РБД в другую.

Диспетчеризация ODBC-хозяйства

Предложенный метод абстрагирования от конкретных РБД безусловно хорош, но постоянная перелинковка ODBC-библиотек при переключении между различными базами - не самое интересное и заманчивое решение. Существуют методы, позволяющие подгружать динамические библиотеки на лету, но это довольно сложная область программирования. Для решения такой проблемы было выпущено такое решение, как ODBC-диспетчеры (или менеджеры). Диспетчер представлен своей собственной ODBC-библиотекой, которая, на самом деле, является заглушкой и перегружает свои вызовы на вызовы конкретного ODBC-драйвера по требованию приложения. Естественно, что библиотека диспетчера расширена функциями, позволяющими переключаться между базами не вдаваясь в подробности динамической линковки "на лету". Также существует управляющий софт, который конфигурируется диспетчером, сообщает ему параметры и местоположение конечных ODBC-драйверов. Таким образом, приложению достаточно быть слинкованным с ODBC-библиотекой диспетчера, и ему сразу после этого становятся доступны все ODBC-драйверы, прописанные в системе. При этом приложение даже не оперирует понятием драйвера, а использует так называемые DSN (Data Source Name). Практически все современные ODBC-драйверы, поставляемые с базами данных, рассчитаны на управление диспетчером (что, конечно, не мешает в случае надобности линковаться с ними напрямую).

Форточки и ODBC

В современных операционных системах от Microsoft компонент ODBC-диспетчера и некоторый набор ODBC-драйверов уже входит в поставку дистрибутива. Доступ к диспетчеру осуществляется через панель управления посредством элемента "Источники данных (ODBC)" (папка "Администрирование"). При установке все ODBC-драйверы прописываются в системе, их список можно посмотреть во вкладке диспетчера "Драйверы". На базе установленных драйверов можно заводить DSN'ы - описатели соединения с базой данных, указывающие, помимо драйвера, специфичные для базы параметры. Именно этими DSN'ами и будет потом оперировать конечное приложение. Под аккаунтом администратора можно заводить системные DSN'ы, которые будут доступны всем пользователям. Непривилегированный пользователь может заводить пользовательские DSN'ы, доступные только ему. Остальные вкладки предназначены для отладочной трассировки, оптимизации подключений, совместного использования пользовательских DSN'ов и других специфических целей.