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

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

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

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

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

ADO - это мир Microsoft

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Microsoft SQL Server с ADO

  • IBX не очень любит Firebird.

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

- jeroen