Хроники DataBase Connectivity

Alexander S. Salieff

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

(salieff@mail.ru)

История развития интерфейсов доступа к базам данных

Рынок баз данных является важным сегментом современной IT-индустрии. Но не всегда БД были такими, какими мы привыкли их видеть: они пережили тяжелые годы развития, прежде чем дошли до своего современного состояния.

Базы данных существуют не в вакууме, а в окружении множества технологий. Люди общаются с БД через терминалы с помощью унифицированного языка, программы используют унифицированные технологии доступа. Все эти стандарты возникли не на пустом месте: они являются частью той истории, которую я сейчас расскажу.

Автоматизация производства. ODBC

Сорок лет назад нормальное использование базы данных в подавляющем большинстве случаев можно было представить примерно так: оператор сидит за терминалом СУБД и вручную делает выборки. В скором времени автоматизация производства проникла и сюда: с началом внедрения автономных программных комплексов базы данных услуги человека-работника стали ненужными. На тот момент стандарты описывали лишь логику построения РБД и язык SQL, призванный стать унифицированным интерфейсом между человеком и СУРБД, но не между программой и СУРБД. Как и всегда в подобных ситуациях, в мире воцарился хаос: каждый производитель пытался протолкнуть свой программный интерфейс доступа и навязать его потребителю. Устав от этого бардака, наиболее сознательные производители объединились в группу SAG (SQL Access Group), которая занялась разработкой унифицированного CLI (Call Level Interface, а проще - "библиотека функций"), позволяющего приложениям работать с базами данных. Разработка оказалась удачной и была стандартизирована ISO и EIC. Стандарт ISO/EIC DBC CLI не слишком удобен и гибок по современным нормам, перегружен низкоуровневыми рутинными операциями, но он впервые позволил программистам писать системы, взаимодействующие с РБД, и малой кровью переносить их между базами различных производителей.

В 1992 году небезызвестная компания Microsoft с небольшим опозданием обратила внимание на популярность и востребованность технологий, связанных с реляционными базами данных. Завоевать этот сегмент рынка засильем своих технологий к тому времени уже не представлялось возможным, поэтому новый продукт компании основывался на ISO/EIC CLI и получил название ODBC - Open Database Connectivity. Проект ODBC отличался от своего предка расширенным набором функций и разделением на два компонента: ODBC-драйверы, предоставляющие непосредственный доступ к БД, и ODBC-диспетчер (менеджер) который с одной стороны управляет драйверами, а с другой взаимодействует с прикладным ПО. Такой подход позволяет ODBC-приложениям полностью абстрагироваться от специфики конкретной РДБ, легко переключаясь между ними даже в процессе работы.

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

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-драйверами.