ADO или DBX с использованием Delphi
https://stackoverflow.com/questions/1305531
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Что лучше (и по каким причинам) использовать для подключения к MS SQL, Oracle или Firebird из приложения Delphi Win32 - ADO или DBX (Database Express)?
Оба позволяют вам подключаться к основным базам данных.Мне нравится, как ADO делает все это с изменением строки подключения и тем фактом, что ADO и драйверы включены в Windows, поэтому ничего лишнего для развертывания (кажется, поправьте меня, если я ошибаюсь).
DBX также является гибким, и я могу скомпилировать драйверы в свое приложение, не так ли?
Я действительно стремлюсь иметь единый источник, если это возможно, с возможностью варьировать базы данных в зависимости от ИТ-отдела / предпочтений заказчика.
Но что проще программировать, работает лучше, использует память наиболее эффективно?Есть еще какие-нибудь вещи, по которым их можно отличить?
Спасибо, Ричард
Решение
ADO прост в использовании и есть, вам нужно только убедиться в установке соответствующего клиентского драйвера на стороне клиента.
Я нашел DBX более гибким, и он лучше интегрирован в IDE и другие технологии, такие как DataSnap.
Для той же цели, что и вы, я использовал DBX со сторонними драйверами от ДевАрт.Вы можете скомпилировать драйверы с вашим приложением, если купите исходные тексты драйверов.
Другие советы
В начале разработки Delphi люди хвалили поддержку нескольких СУБД в Delphi.Всем понравился BDE (потому что это был единственный способ сделать это).
Но, наблюдая за клиентами более чем за последнее десятилетие, я видел неуклонное снижение поддержки нескольких СУБД в их приложениях.
Стоимость поддержки нескольких СУБД из одного приложения высока.
Не только потому, что вы должны обладать знаниями о каждой СУБД, но и потому, что каждая СУБД имеет свой собственный набор особенностей, к которым вы должны адаптироваться на вашем уровне доступа к данным.Они включают в себя различия не только в синтаксисе и базовых типах данных, но и в стратегиях оптимизации.
Кроме того, некоторые СУБД лучше работают с ADO, некоторые лучше с прямым подключением (например, пропуская ваш клиент Oracle все вместе).
Наконец, тестирование всех комбинаций вашего программного обеспечения с несколькими системами СУБД является очень интенсивным.
Я участвовал в нескольких проектах, где нам пришлось изменить серверную часть СУБД и / или технологию доступа к данным (т.е.BDE к DBX или из DBX к прямому соединению).Изменение серверной части всегда было гораздо более болезненным процессом, чем изменение технологии доступа к данным.Многоуровневые подходы несколько упростили их, но увеличили степени свободы и, следовательно, усилия по тестированию.
Некоторые из продуктов, которые, как я вижу, поддерживают МУЛЬТИСУБД, представлены в приложениях вертикального рынка, где конечный заказчик уже имеет свою собственную инфраструктуру СУБД, и приложению необходимо адаптироваться к ней.Например, в голландских правительственных районах Oracle был действительно силен, но SQL Server также создал неплохую базу пользователей.
Поэтому вам нужно подумать о том, какие комбинации СУБД вы хотите поддерживать, не только с точки зрения функциональности, но и с точки зрения стоимости.
Если вы придерживаетесь одной СУБД, то нет смысла использовать общий уровень доступа к данным, такой как BDE, DBX или ADO:это окупается тем, что соединение становится как можно более прямым.Мой опыт научил меня, что эти комбинации действительно хорошо работают:
- Interbase или Firebird с ФИБПлюс, АныДАК, ИБО или IBX*
- Оракул с АныДАК, ДОА или ODAC
Microsoft SQL Server с ШУМИХА
- IBX не очень любит Firebird.
Надеюсь, это даст вам некоторое представление о возможностях и ограничениях поддержки нескольких СУБД из ваших приложений Delphi.
--джерун
Общее правило:каждый слой компонентов, возможно, добавит дополнительный слой ошибок.И ADO, и DBX являются оболочками компонентов вокруг стандартной функциональности базы данных, таким образом, они оба одинаково эффективны.Таким образом, правильный выбор должен основываться на других факторах, таких как базы данных, которые вы хотите использовать.Если вы хотите подключиться к MS-Access или SQL Server, ADO будет лучшим выбором, поскольку он более подходит для этих баз данных.Но Firebird и Oracle являются более родными для компонентов DBX.
Однако лично я предпочитаю использовать необработанные API ADO.С другой стороны, я не использую компоненты, ориентированные на данные, в своих проектах.Это менее радужно, я знаю.Но мне часто приходится работать таким образом, потому что я обычно пишу клиент-серверные приложения с несколькими уровнями между базой данных и графическим интерфейсом, что усложняет задачу.
Мои два цента:DBX значительно быстрее (как в Oracle, так и в sql), а также значительно более требовательна и сложнее в развертывании.
Если производительность является фактором, я бы выбрал DBX.В противном случае я бы просто использовал ADO для простоты.
Как уже говорили другие, DBX может иметь преимущество в производительности raw в определенных случаях или при определенных обстоятельствах, но ADO является основой для гораздо большего числа приложений в мире, поэтому, хотя производительность ADO может быть относительно ниже, очевидно, что это не означает "неприемлемо" низкую.
Для меня и по опыту крупных проектов, над которыми я работал, самая большая "проблема" DBX заключается в том, что независимо от того, насколько она хороша, это ключевая инфраструктурная технология, предоставляемая компанией, занимающейся языковыми инструментами.
Любой, кто создавал приложения на предыдущей технологии BDE, засвидетельствует сбои, вызванные тем, что эта технология устарела и больше не поддерживается.Хотя ни одна технология не застрахована от устаревания со стороны ее поставщика, ADO явно имеет преимущество, когда дело доходит до поддержки отрасли помимо самих поставщиков технологий.
По этой причине я сам теперь всегда использую ADO.Однако простое изменение строки подключения - не всегда единственное, о чем следует беспокоиться при переходе с одного типа базы данных на другой.Синтаксис вызова хранимой процедуры может варьироваться от одного поставщика ADO к другому, и вам все равно придется следить за используемым синтаксисом SQL, если вы собираетесь выполнять развертывание на нескольких разных ядрах SQL, где поддержка SQL может варьироваться от одного к другому.
Чтобы смягчить эти проблемы, я использую свою собственную инкапсуляцию объектной модели ADO.Эта инкапсуляция не пытается преобразовать объектную модель во что-то, что не похоже на ADO, она просто предоставляет те части ADO, которые мне нужно использовать непосредственно, в более удобной для ObjectPascal (и безопасной для "типа") форме (например, перечисляемые типы и наборы для констант и флагов и т.д., А не просто десятки, если не сотни целочисленных констант).
Моя инкапсуляция также учитывает некоторые незначительные различия в поведении / требованиях различных поставщиков, такие как ранее упомянутые различия в синтаксисе вызова хранимой процедуры.
Я должен также сказать, что, подобно другому плакату, я слишком давно перестал использовать "средства управления с учетом данных", которые открывают этот подход.Если вам нужны или вы хотите использовать элементы управления с поддержкой данных и хотите использовать ADO, то вы не можете использовать ADO напрямую и должны вместо этого найти некоторую инкапсуляцию, которая предоставляет ADO через модель набора данных VCL.
ADO - это мир Microsoft
DBX был создан в самом начале (Delphi 6) для кроссплатформенности и Kylix
