Не microsoft'ом единым. Bde

В 1990 году компания dBase (а вместе с ней и БД dBase, и Paradox) перешли в собственность Borland. В то время даже БД, заявленные как работающие с одинаковыми формата­ми, были несовместимы друг с другом из-за уймы мелких различий. Таким образом, у Borland в наличии оказа­лись две несовместимых БД, на раз­витие и поддержку которых требова­лись удвоенные усилия. Выходом из создавшейся ситуации была разра­ботка модели ODAPI 1.0 - Open Database Application Programming Interface, позволявшей единообразно обращаться к БД dBase и Paradox посредством механизма QBE (Query By Example). Вскоре были разработа­ны дополнения, подрастившие ODAPI до версии 1.1 и позволившие общать­ся в том же стиле с Interbase, Oracle, Sybase и MS SQL. В версии 2.0 ODAPI превратилась в IDAPI (перестала быть "открытой" и стала "интегрирован­ной"), проект заметили, им заинтере­совались крупные корпорации вроде IBM, Novell и Wordperfect. Появилось локальное SQL-ядро, позволяющее работать с локальными файлами БД без самой СУБД, и IDAPtor - мост меж­ду IDAPI и ODBC. Дожив до версии 3.0, IDAPI стала 32-разрядной и сме­нила имя на BDE (Borland DataBase Engine). С тех пор BDE так и не изме­нила логической структуры, а только обросла новыми драйверами и моста­ми взаимодействия с современными DBC-технологиями.

зитивные моменты предшественника, исправить недостатки и привнести но­вые достоинства. Одним из ключевых моментов можно считать интерес Borland к UNIX-платформам и абсо­лютную платформенно-архитектур-ную непереносимость BDE (в Kylix нет BDE). Также dbExpress имеет легкую модульную архитектуру, открытую к дополнениям (основа весит 500 Kб против почти десятимегабайтного мо­нолита BDE). Конфигурация вынесена из реестра в удобочитаемые тексто­вые файлы, а большинство основных интерфейсных объектов обзавелось немалым количеством механизмов тонкой настройки.

Odbc на практике

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

BDE УМЕР. ДА ЗДРАВСТВУЕТ DBEXPRESS!

Несмотря на своевременное появ­ление, удачные идеи и популярность среди программистов, BDE объектив­но сдает свои позиции более слабому и легковесному конкуренту - ODBC. На сегодняшний день BDE повсеместно считается устаревшей, тяжеловесной и неудобной в администрировании технологией. Borland официально за­явила о прекращении развития и под­держки BDE в пользу более прогрес­сивного преемника - dbExpress. Новый механизм призван сохранить все по ODBC-библиотеками, мож­но безболезненно мигрировать из од­ной РБД в другую.

ДИСПЕТЧЕРИЗАЦИЯ ODBC-ХОЗЯЙСТВА

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