Версия для печати


Дилемма доступа к данным.
http://www.delphikingdom.com/asp/viewitem.asp?catalogID=70

Юрий Ёлкин
дата публикации 10-01-2000 00:00

Дилемма доступа к данным.Перевод с английского.

Оригинал можно прочесть здесь

Автор: Марко Кэнту (Marco Cantu)
Copyright 1999, Inprise Corporation, all rights reserved
Article ID:20191 Publish Date: December 01, 1999 Last Modified: December 01, 1999
 

По традиции, приложения Delphi использовали технологию BDE для доступа к данным. Но с появлением Delhi 5 появилась новая возможность - ADO.

С момента появления Delphi 5, который включает технологию ADOExpress ( она входит в Delphi Enterprise или продается как отдельная опция к Delphi Professional), программисты встретились с выбором: что использовать BDE или ADO для доступа к БД ? Типичным ответом на вопрос "Какую технологию Баз Данных использовать ?" будет - "Это зависит от ..."

Технология BDE ( http://www.borland.com/bde ) имеет длинную и славную историю. Она появилась в Delphi 1 в качестве механизма для доступа к таблицам Paradox и, позднее, была частью ISAPI - инициативы поддерживаемой IBM, Novell и WordPerfect. Несмотря на некоторые проблемы, BDE является одной из причин успеха Delphi на арене Баз Данных и достигнув версии 5 она является достаточно зрелой технологией. И хотя есть несколько проблем в процессе программирования и установки готовых программ, Delphi - программисты научились жить с BDE.

Несколько белых пятен.

Так зачем уходить от BDE ? Разворачивание ее на арендуемых Internet серверах зачастую невозможно из-за неодобрения ISP'ом запуска сервисов системного уровня на своих серверах. И хотя BDE была усилена для поддержки таких возможностей, как обьектно-реляционная модель Oracle 8, некоторые из ее возможностей все еще сдерживаются ее Paradox корнями. Например, способ сопоставления числовых полей Базы Данных и типов переменных создает проблемы совместимости при работе Delphi с различными SQL серверами. Другая проблема в том, что BDE полностью включает ядро, используемое Paradox и dBase для доступа к данным. Нет возможности поставлять облегченную версию BDE исключив поддержку Paradox'а, если вы работаете только с SQL серверами. (С другой стороны, некоторые из этих проблем, такие как работа SQL сервера на ISP сервере, актуальны и для использования ADO.)

В конце концов, с приходом Kylix (технология Delphi и C++Builder для Linux), мы увидим версию Delphi которая не сможет использовать BDE, но очевидно будет базироваться на новом облегченном ядре. Если для BDE нет места в будущем Delphi для Linux, она врядли может считаться будущим и для Windows. Borland продолжает утверждать, что BDE остается, но как мы видим за последние пару лет разрабатывается очень мало.

Технология ActiveX Data Objects (ADO) это разработка Microsoft. Она предоставляет упрощенный способ для доступа к данным основанный на OLE DB, сама же мощная лошадка остается за сценой. Программировать непосредственно на OLE DB уровне достаточно сложно, поэтому Microsoft предоставляет более простое решение.

Включая технологию ADOExpress в Delphi Borland принял ADO в качестве общей технологии и признал Microsoft Access, как широко распространенный механизм доступа к БД (Прим.перев.: с полгода назад Microsoft заключил серию соглашений с Inprise- Microsoft заплатил в общей сложности порядка 250 млн. долларов за поддержку его технологий в продуктах Inprise). Не смотря на то, что в последнее время вы уже могли использовать БД Access через BDE, возможности все же были ограничены. Microsoft также установил несколько препятствий на дороге - таких как сокрытие новой версии DAO, фронтэнд Access'a обычно используемый в Visual Basic - чтобы подтолкнуть других поставщиков средств разработки для Windows в сторону ADO.

Так или иначе, ADO это достаточно интересная технология. Она оптимально "легковесная", достаточно мощная, предоставляет доступ к данным вне реляционных БД, и Microsoft пытается продвинуть ее в качестве открытого стандарта. Вы даже можете написать OLE DB провайдера для ADO в Delphi.

Потеря управления.

Хотя ADO и умное решение, есть одна вещь, которая мне не нравится: вы теряете контроль, который предоставляет BDE. BDE ограничена в своей возможности обновлять результат запроса, поэтому чтобы использовать живые запросы (live queries) в Delphi вы часто используете компонент UpdateSql, а с SQL предложениями для замены, вставки и удаления - компонент Query. Это может показаться неудобным, но на самом деле позволяет сделать значительную тонкую настройку вашего приложения. ADO с другой стороны, делает много работы, чтобы обновлять результат запроса без какого либо дополнительного кодирования, но у вас нет контроля над SQL-кодом посылаемым серверам, если только Вы не разместили собственное решение отбросив живые запросы. Некоторая тонкая настройка доступна в ADO через использование DataSet'a, курсора, и блокировочных опций, но эти возможности ведут себя по разному на разных SQL серверах и, как оказывается, тонко настраиваются только для Microsoft SQL Server и Access.

Рассмотрим последнее подробнее: Несмотря на то, что использование ADO для доступа к нескольким базам данных является хорошей идеей, есть несколько возможностей в ADO , которые похоже связаны только с Access. Например, Access является единственной, из всех что я знаю, базой данных, в которой вы имеете возможность блокирования записей при чтении на случай, если вы захотите редактировать их в будущем. Как и BDE включает в себя некоторые Paradox-специфичные возможности, так и ADO включает несколько возможностей, которые более Access-ориентированы, чем должно было бы предоставлять универсальное средство доступа к данным.

Некоторые из наиболее интересных возможностей ADO связаны с использованием курсоров со стороны клиента. Вы можете скопировать полностью набор данных на клиентский компьютер и выполнить ряд операций на этом кэше, включая сортировку, фильтрацию и редактирование данных. Вы можете даже скопировать часть данных в локальный файл и работать с ним в режиме offline. Примеры, как это сделать, есть в Delphi 5/demos и на моем сайте .

BDE тоже выполняет кэширование на локальном компьютере, но не позволит вам работать с кэшем. Однако, довольно много Delphi программистов научились использовать компонент ClientDataSet для работы с кэшированными данными. Я исследовал этот предмет и пришел к заключению, что ClientDataSet делает все, что делает клиентский (client-side) курсор ADO, включая сортировку, фильтрацию и локальное кэширование выборки из набора данных (local snapshots). Обе технологии позволяют вам создать локальный набор данных наложенный (mapped to) на файл в удаленной базе данных без соединения с ней. Обе имеют поддержку для XML - хотя и различными путями. Обе могут быть использованы для построения трехуровневых приложений. И обе предоставляют вложенные (nested) таблицы для создания master-detail представлений данных.

В дополнение, компонент ClientDataSet предоставляет некоторые продвинутые возможности не поддерживаемые в ADO: группирование, аггрегирование, вычисляемые поля и поддержка абстрактных типов данных ( вот пример ). ClientDataSet и связанный с ним компонент провайдера предоставляет намного больше возможностей управления, чем в ADO. Возможно не только точно указать как будет выпоняться запись данных, но у вас имеются большие возможности для обработки конфликтов записи.

Обилие опций

ADO и BDE не единственная альтернатива для доступа к данным в Delphi. Есть и другие компоненты наборов данных производимых Borland и третьими фирмами для непосредственного доступа к SQL серверам, таким как Oracle и Interbase. Есть также альтернативы для ADO - это разработки, которые предоставляют прямой доступ к DAO, и другие альтернативные технологии поддерживающие от Btrieve до AS/400. Но я все еще не нашел решения для прямого OLE DB доступа.

BDE больше не является общим знаменателем для доступа к базам данных в Delphi. Я даже написал пару dataset'ов для доступа к данным не из баз данных. Вы, разумеется, не нуждаетесь в ADO и специальных OLE DB провайдерах для этого.

Oracle, один из предпочтительных back-end серверов для Delphi приложений, наслаждается таким широкораспространенным использованием (колоритная фраза, я не стал ее "русифицировать"- прим.перев.), что я подозреваю, что успех ADO стратегии в значительной степени зависит от поддержки Oracle - по крайней мере с точки зрения перспективы для Delphi разработчиков. Очевидно, что поставляемый Microsoft'ом OLE DB провайдер для Oracle на сегодня не является ни живучим, ни полным решением. Если Oracle не подтолкнет ADO, то будущее этой технологии не видится столь ярким. А поскольку Microsoft наращивает ADO в направлении к собственным реализациям баз данных, то становится понятным сопротивление Oracle'a продвижению ADO.

Самое большое преимущество технологии ADO в том, что она широко распространена в Windows и продвигается фирмой Microsoft. Если вам нужен доступ к базам данных Microsoft SQL Server или Access, то вы вероятно предпочтете использовать ADO. Если вы используете Paradox или Interbase, тогда вам вероятно лучше поставить на BDE - если только вы не погрузились на корабль "InterBase Express". С таким большим количеством вопросов в программном бизнесе, ответом на "Какую технологию мне надо бы использовать ?" будет : "Это зависит от ..."