ADO или DBX с использованием Delphi - PullRequest
6 голосов
/ 20 августа 2009

Что лучше (и по каким причинам) использовать для подключения к MS SQL, Oracle или Firebird из приложения Delphi Win32 - ADO или DBX (Database Express)?

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

DBX также гибок, и я могу скомпилировать драйверы в свое приложение, не так ли?

Я действительно заинтересован в том, чтобы по возможности иметь единый источник с возможностью варьировать базы данных в зависимости от ИТ-отдела / предпочтений заказчика.

Но что легче программировать, работать лучше, использовать память наиболее эффективно? Любые другие вещи, чтобы дифференцировать их?

Спасибо, Ричард

Ответы [ 6 ]

7 голосов
/ 20 августа 2009

ADO прост в использовании и есть, вы должны только установить соответствующий клиентский драйвер на стороне клиента.

Я нашел DBX более гибким и лучше интегрированным в IDE и другие технологии, такие как DataSnap.

Для той же цели, что и вы, я использовал DBX со сторонними драйверами от DevArt . Вы можете скомпилировать драйверы с вашим приложением, если купите источники драйверов.

5 голосов
/ 21 августа 2009

В начале Delphi люди хвалили поддержку нескольких СУБД в Delphi. Все любили BDE (потому что это был единственный способ сделать это).

Но, рассматривая клиентов более чем за последнее десятилетие, я наблюдал неуклонное снижение поддержки нескольких СУБД в их приложениях.

Высокая стоимость поддержки нескольких СУБД из одного приложения.

Не только потому, что вы должны знать каждую СУБД, но и потому, что каждая СУБД имеет свой собственный набор особенностей, к которым вы должны адаптироваться на уровне доступа к данным. К ним относятся не только различия в синтаксисе и базовых типах данных, но и стратегии оптимизации.

Кроме того, некоторые СУБД лучше работают с ADO, некоторые лучше с прямым соединением (например, пропуская ваш клиент Oracle вместе).

Наконец, очень интенсивно тестируется все комбинации вашего программного обеспечения с несколькими системами СУБД.

Я принимал участие в нескольких проектах, в которых нам приходилось менять бэкэнд СУБД и / или технологию доступа к данным (с BDE на DBX или с DBX на прямое соединение). Смена бэкэнда всегда была намного сложнее, чем изменение технологии доступа к данным. Многоуровневые подходы сделали их несколько проще, но увеличили степень свободы и тем самым усилия по тестированию.

Некоторые из продуктов, которые, на мой взгляд, поддерживают мульти-СУБД, используются в приложениях вертикального рынка, где конечный клиент уже имеет свою собственную инфраструктуру СУБД, и приложение должно адаптироваться к этому. Например, в правительственных районах Нидерландов Oracle был очень силен, но SQL Server также создал достаточно пользователей.

Так что вам нужно подумать о том, какие комбинации СУБД вы хотите поддерживать не только с точки зрения функциональности, но и с точки зрения стоимости.

Если вы придерживаетесь одной СУБД, то нет смысла переходить на общий уровень доступа к данным, такой как BDE, DBX или ADO: он окупается, устанавливая соединение как можно более прямым. Мой опыт научил меня, что эти комбинации хорошо работают:

Надеюсь, это даст вам некоторое представление о возможностях и ограничениях поддержки нескольких СУБД из ваших приложений Delphi.

- Йерун

4 голосов
/ 21 августа 2009

Мои два цента: DBX значительно быстрее (как на oracle, так и на sql) и значительно более требователен и сложен в развертывании.

Если бы производительность была фактором, я бы выбрал DBX. В противном случае я бы просто использовал ADO для простоты.

4 голосов
/ 20 августа 2009

Общее правило: каждый слой компонентов, возможно, добавит дополнительный слой ошибок. И ADO, и DBX являются оболочками компонентов для стандартных функций базы данных, поэтому они оба одинаково сильны. Поэтому правильный выбор должен основываться на других факторах, таких как базы данных, которые вы хотите использовать. Если вы хотите подключиться к MS-Access или SQL Server, лучше выбрать ADO, поскольку он более естественный для этих баз данных. Но Firebird и Oracle более родные для компонентов DBX.

Лично я склонен использовать сырые API ADO. Опять же, я не использую компоненты, учитывающие данные, в своих проектах. Это менее RAD, я знаю. Но мне часто приходится работать таким образом, потому что я обычно пишу клиент-серверные приложения с несколькими уровнями между базой данных и графическим интерфейсом, что усложняет ситуацию.

2 голосов
/ 21 августа 2009

Как уже говорили другие, DBX может иметь преимущество в необработанной производительности в определенных случаях или при определенных обстоятельствах, но ADO является основой для очень большого числа приложений в мире, поэтому, хотя производительность ADO может быть относительно ниже, ясно это не означает «неприемлемо» бедных.

Для меня и, как мне сообщили крупные проекты, над которыми я работал, самая большая «проблема» с DBX заключается в том, что, как бы хорошо это ни было, это ключевая инфраструктурная технология, предоставляемая компанией, специализирующейся на языках и инструментах.

Любой, кто создавал приложения на основе предыдущей технологии BDE, будет свидетельствовать о сбое, вызванном устаревшей технологией, которая больше не поддерживается. Несмотря на то, что ни одна технология не защищена от устаревания ее провайдером, ADO явно имеет преимущество, когда речь заходит о поддержке отрасли, помимо самих поставщиков технологий.

По этой причине я сам сейчас всегда использую ADO. Простое изменение строки подключения - не всегда единственное, о чем нужно беспокоиться при переходе с одного типа базы данных на другой. Синтаксис вызова хранимой процедуры может варьироваться от одного поставщика ADO к другому, и вам все равно придется следить за синтаксисом SQL, который вы используете, если вы собираетесь развертывать на нескольких различных механизмах SQL, где поддержка SQL может отличаться от другой.

Чтобы смягчить эти проблемы, я использую собственную инкапсуляцию объектной модели ADO. Эта инкапсуляция не пытается преобразовать объектную модель во что-то, что не похоже на ADO, она просто предоставляет те части ADO, которые мне нужно использовать напрямую, в более дружественной к ObjectPascal (и «type» безопасной) форме (например, типы enum и наборы для констант, флагов и т. д., а не просто оценки, если не сотни целочисленных констант).

Моя инкапсуляция также учитывает некоторые незначительные различия в поведении / требованиях различных поставщиков, такие как ранее упомянутые различия в синтаксисе вызова хранимых процедур.

Я должен также сказать, что, подобно другому постеру, я слишком давно перестал использовать «элементы управления данными», что открывает этот подход. Если вам нужно или вы хотите использовать элементы управления с учетом данных и хотите использовать ADO, то вы не можете использовать ADO напрямую, а вместо этого должны найти некоторую инкапсуляцию, которая предоставляет ADO через модель набора данных VCL.

0 голосов
/ 21 августа 2009

ADO - это мир Microsoft

DBX был создан в начале (Delphi 6) для кроссплатформенности и Kylix

...