Кофе. Солнце. Базы данных

Java-технологии компании Sun Microsystems тоже не оставили в сто­роне доступ к РБД. Разработка компа­ний JavaSoft и InterSolv была призва­на удовлетворить потребность в DataBase Connectivity применительно к java-приложениям. Как и следовало , этот проект во многом опирался на опыт создания ODBC и получил похожее название - JDBC (Java DataBase Connectivity). Первые реализации JDBC по сути представля­ли собой java-обертку вокруг ODBC-библиотек. Я не хочу сказать, что это решение убого или не достойно вни­мания: подобная технология активно применяется в наши дни и ее принято называть "мост JDBC-ODBC". Однако позже появились системы, в которых java-технологии занимали чуть ли не ведущую архитектурную позицию, и вместе с ними появились и "чистые" реализации JDBC, которые представ­ляли собой java-классы, способные самостоятельно общаться с СУРБД, то есть без помощи дополнительных ODBC-драйверов. И пусть это реше­ние проигрывало по производитель­ности JDBC-ODBC-мостам, но оно бы­ло незаменимо в системах, имеющих на борту JVM (Java Virtual Machine), но не располагающих родными ODBC-драйверами.

DAO И RDO

Для БД Microsoft Access был раз­работан специализированный БД-процессор Microsoft JET. Он предос­тавлял пользовательским приложе ниям интерфейс, отличающийся от ODBC ярко выраженной объектно-компонентной моделью, что позволи­ло выполнить полноценную интер­фейсную привязку не только к низко­уровневым языкам вроде C/C++, но и к менее гибким наподобие Visual Basic. Технология получила имя DAO -Data Access Object. Из-за тенденции унификации интерфейс DAO был рас­ширен на многие БД помимо MS Access. Однако однозначная заточен-ность под JET вынуждала транслиро­вать JET-команды в ODBC-инструкции (при доступе к не-Access БД), что сни­жало производительность. Пришлось разработать первичный binding ODBC в DAO-интерфейс, получивший назва­ние RDO (Remote Data Objects). Те­перь при доступе к БД через ODBC больше не требуется производить за­медляющую JET-ODBC-трансляцию. DAO-доступ через RDO принято назы­вать DAO-ODBCDirect.

OLE DB

Понятно, что технология Object Linking and Embedding (OLE), которую агитаторы Microsoft когда-то активно продвигали в массы, не могла не по­влиять на интерфейсы DBC. OLE DB предлагает концепцию, несколько от­личающуюся от описанных выше ме­тодов. Здесь содержимое БД предс­тавлено в виде данных документа и публичного интерфейса приложения, способного обработать этот документ (собственно, это и есть стандартная для OLE модель). С одной стороны, это мало похоже на привычные моде­ли с запросами данных и возвратами результатов, а с другой - позволяет осуществлять привязки OLE DB к не-SQL (и даже к не-реляционным) базам данных. СУБД должна предоставить свой публичный OLE-интерфейс для работы с данными, и тогда можно бу­дет использовать через OLE-DB. Есть и другой (весьма популярный для SQL РБД) метод - OLE DB-надстройка над механизмами ODBC.

ADO

Серверы интерфейсной автомати­зации тоже оставили свой след на многострадальном теле DBC. В эпоху расцвета CORBA, DCOP и прочего Microsoft продвигала свое видение операционно-объектного интерфейса по имени COM (Common Object Methods). Детище концепций COM/DCOM получило имя ADO -ActiveX Data Objects. ADO не оснащено средствами для работы с различными БД напрямую. Вместо этого использу­ются объектные платформы DAO/RDO и OLE DB, обретающие COM-привязки в лице ADO-интерфейса.

ADO+ AKA ADO.NET

Конечно же, не обошлось без пришествия .NET в стан DBC. На са­мом деле (по крайней мере, если ве­рить заявлениям Microsoft) ADO.NET и ADO имеют лишь одинаковые назва­ния и их программные интерфейсы слегка похожи. ADO.NET базируется на полностью переработанном движ­ке, имеющем существенные отличия в плане возможностей. Во-первых, это, ясное дело, интеграция с .NET Framework. Во-вторых - тесная интег­рация с XML. Этим, похоже, сейчас бо­леют все и впихивают этот самый злосчастный XML куда надо и не на­до. И третьей отличительной чертой ADO.NET от ADO является поддержка модели доступа к несвязанным дан­ным. На практике это означает, что приложение может отсоединяться и присоединяться к БД практически в произвольном порядке, что больше похоже на транзакции в WWW-сессии, чем на старый стиль запроса и полу­чения данных в рамках одного неде­лимого соединения.