ADO или DBX с использованием Delphi

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

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

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

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

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

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

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

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

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

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

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

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

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

• Interbase или Firebird с FIBPlus, AnyDAC, IBO или IBX *
• Oracle с AnyDAC, DOA или ODAC

• Microsoft SQL Server с ADO

  • IBX does not like Firebird very much.

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

- Джерун

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

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

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

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

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

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

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

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

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

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

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

ADO - это мир Microsoft

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