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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

АДО Microsoft мир

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

Answer 4

Мои два цента: DBX значительно быстрее (на обоих оракула и SQL), и значительно более более сложной и сложной для развертывания.

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

Answer 5

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

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

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

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

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

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

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

Answer 6

В начале 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 не любит Fi rebird очень много.

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

--jeroen