|
Дилемма доступа к данным
Оформил: DeeCo Автор: Марко Кэнту (Marco Cantu)
Несколько белых пятен.
Так зачем уходить от 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". С таким большим количеством вопросов в программном бизнесе, ответом на "Какую технологию мне надо бы использовать ?" будет : "Это зависит от ..." |
Автор проекта: ___Nikolay