Архитектура ODBC, JDBC, OCI, OLE DB и ADO
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–овских СУБД.
Таким образом, промежуточное программное обеспечение достаточно большое. Клиент в ручном режиме настраивает псевдоним и указывает путь для базы данных, выбирает драйвер. Когда клиент обращается, то он обращается к driver managerу, берет нужный драйвер, а нужный драйвер бывает часто записан в этих файлах, а в последнее время в реестре Windows (лезет в реестр Windows и находит драйвер, подключает этот драйвер и обращается к БД).
ODBC API
ODBC API включает около 56 функций. Это было создано в 1992 году, поэтому она реализована на уровне функций, т.е. имеет функциональное представление.
Чуть позже был разработан 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), если провайдер имеется.
connection
– организует соединение базы данных, т.е. инкапсулирует все сведения о соединении: имя базы данных и т.д. и т.д.command – объект имеющий методы для выполнения команд.
streams – работа с потоками.
fields – для работы с полями.
Такова архитектура ADO для доступа базам данных, т.е. это небольшой комплект объектов, у которого есть некоторый набор методов, с помощью которых считывать записи напрямую через потоки, если из файлов считывать и т.д.
Таким образом к сегодняшнему дню сформировано целое направление промежуточного программного обеспечения (ODBC, JDBC, ADO, OLE DB, BDE, OCI), назначение которого дать возможность разрабатывать клиентские приложения на различных языках и подключаться к существующим базам данных. Для этого нужные только драйверы и вот это промежуточное ПО, которое может работать с этими драйверами. Тем самым “был развязан узел” между поставщиками баз банных и поставщиков языков, они конечно поставляли языки но средства были очень и очень ограничены.
- либо через потоки управления (явно);
- либо через определяемые потоки данных (неявно).
|
|
 |