ODBC
Допустим, есть клиент, написанный к примеру на Visual C, есть база данных (ORACLE, MS SQL) и целая куча разных Desktops БД (Access, dBase, Paradox, Excel и т.д.). Как же происходит взаимодействие? Прежде всего, в системе устанавливается Microsoft Driver Manager (odbc32.dll). Эта dll-ка взаимодействует иногда с odbcint.ini и odbc.ini. Для работы с этой dll-кой есть администратор, который позволяет подключать драйверы (то что мы видим в панели управления).

Есть ODBC Administrator – это ничто иное, как odbcad32.exe, odbccp32.dll и odbccp32.cpl – видим в панели управления. С помощью этих средств мы запускаем администратор (через пиктограмму odbccp32.cpl), и там можно устанавливать имя базы, подключать драйверы, псевдонимы давать базам данных и т.д. и т.д. Для каждой базы данных в системе должен быть соответствующий драйвер. Например, ODBC driver для ORACLE (как правило, есть в системе); драйвер для MS SQL Server – тоже есть; драйвер, который чаще всего интегрирован, поскольку это базы все простенькие, — odbcjt32.dll – для разных Desktop–вских СУБД.

Рис. Архитектура ODBC

Таким образом, промежуточное программное обеспечение достаточно большое. Клиент в ручном режиме настраивает псевдоним и указывает путь для базы данных, выбирает драйвер. Когда клиент обращается, то он обращается к driver managerу, берет нужный драйвер, а нужный драйвер бывает часто записан в этих файлах, а в последнее время в реестре Windows (лезет в реестр Windows и находит драйвер, подключает этот драйвер и обращается к БД).

ODBC API
ODBC API включает около 56 функций. Это было создано в 92 году, поэтому она реализована на уровне функций, т.е. имеет функциональное представление.

Чуть позже был разработан BDE, который фактически условно считается объектно-ориентированным, но объектно-ориентированного там мало, все равно там есть тоже функции. BDE лучше обеспечивает доступ к Desktop–ким СУБД, поскольку у Borland – а более такие простые базы данных. Там можно настраивать разные языки. Но сейчас это правда никому не нужно, т.к. все драйверы универсальные стали делать, им все равно. Драйверы пропускают просто данные вне зависимости от языка. В результате получилось так, что для использования BDE надо инсталлировать 17мб и не ясно, что из них «можно выбросить», в то время как реализация конкретного доступа на ODBC потребует меньше мегабайта.

JDBC
Стандарт JDBC первоначально разработанный, чтобы иметь доступ к БД по такой же архитектуре сперва включал в себя мост JDBC/ODBC Bridge, а дальше подключались ODBC–шные драйвера. Но с течением времени научились делать и свои драйверы более прямые, и естественно здесь, как говорится, многократное преобразование, а там получилось одно преобразование «и стали более быстрыми».

OCI
Стандарт OCI предназначен только для доступа к базам данных ORACLE. В отличие от Microsoft предлагает немного другой драйвер. Т.е. имеется: клиент, sqloci32.dll, который соединяется с NET8.

Драйвер NET8 всегда есть в базе данных ORACLE. Microsoft, в свою очередь, подключается к ORACLE, минуя NET8 с любой операционной системой, если вы устанавливаете Office, то там этот драйвер есть. Однако сам ORACLE для себя делает более маленькую dll-ку, потому что у него всегда есть драйвер NET8 хорошо отлаженный.

OLE DB и ADO
С течением времени чисто функциональный подход к созданию промежуточного программного обеспечения стал немножко входить в диссонанс с объектно-ориентированными средами разработки, и было разработано два новых стандарта OLE DB и ADO.

Что собой фактически представляют OLE DB и ADO? Общая более современная структура доступа от приложения к БД по мнению Microsoft на сегодня выглядит следующим образом:

Рис. Современная структура доступа от приложения к БД

Есть приложение или клиент, драйверы OLE DB или поставщики, имеется ADO. Вот как по структуре от Microsoft может быть реализован доступ к SQL – им данным и к не SQLским данным (например, к каким-то текстовым данным, тоже есть драйверы). OLE DB провайдеры чисто объектно-ориентированные: там есть классы, объекты, методы. Однако поскольку OLE DB сам стандарт достаточно тяжелый, «такие книги по нему», то для упрощения доступа сделан простой интерфейс ADO, с помощью которого из многих сред таких как Visual Basic, Delphi, и др. можно по-простому обращаться вот таким образом. ODBC никуда не исчез, потому что OLE DB провайдеры. Microsoft сделал только семь провайдеров: для «себя любимого», для ORACLE, для ODBC для всех других баз данных, для текстовых и т.д. всего их 7 штук. Желающих дальше разрабатывать этот провайдер не оказалось, и эта система вот так вот и осталась. Если есть прямой провайдер к MS SQL и ORACLE то можно напрямую (1).

ADO позволяет иметь доступ: либо вот так (2), если провайдера нет, и (3), если провайдер имеется.

Рис. Набор объектов ADO

connection – организует соединение базы данных, т.е. инкапсулирует все сведения о соединении: имя базы данных и т.д. и т.д.
command – объект имеющий методы для выполнения команд.
streams – работа с потоками.
fields – для работы с полями.
Такова архитектура ADO для доступа базам данных, т.е. это небольшой комплект объектов, у которого есть некоторый набор методов, с помощью которых считывать записи напрямую через потоки, если из файлов считывать и т.д.
Таким образом к сегодняшнему дню сформировано целое направление промежуточного программного обеспечения (ODBC, JDBC, ADO, OLE DB, BDE, OCI), назначение которого дать возможность разрабатывать клиентские приложения на различных языках и подключаться к существующим базам данных. Для этого нужные только драйверы и вот это промежуточное ПО, которое может работать с этими драйверами. Тем самым «был развязан узел» между поставщиками баз банных и поставщиков языков, они конечно поставляли языки но средства были очень и очень ограничены.

Комментарии запрещены.