Выбор компонент доступа

iBase Support Team , 03.11.2004, 02.06.2006, 03.06.2010

предупреждение: не ищите здесь сравнения IBX, FIBPlus, IBObjects...

подразумевается, что вы попали в этот документ из общего списка /components/компонент и драйверов. за конкретными ссылками обращайтесь именно туда.

Вводная

Поскольку существует достаточно много компонент доступа к InterBase и Firebird, разработчики приложений при "подходе к снаряду" оказываются перед нелегким выбором. На самом деле выбор можно сделать достаточно легко, и зачастую после формулирования задачи и выбора-то не остается.

У каждого сервера БД есть протокол связи между клиентом и сервером. На 100% этот протокол у разных серверов разный (т.е. драйверов, способных работать более чем с 1-м сервером, не существует). Чаще всего (90%) клиенту предоставляется для связи не "протокол", а готовая библиотека (API) - gds32.dll (InterBase), dbnetlib32.dll (MS SQL), oci.dll (Oracle) и так далее.

Клиентская часть (библиотека, API) достаточно легко переносима между платформами (gds32.dll - Windows, gds.so - Linux). У производителя может быть свое мнение о переносимости, или забота о других вещах - например, есть драйвер ODBC для MS SQL, которому не нужна клиентская часть, он сам осуществляет доступ к серверу по "протоколу". .Net-драйвер для Firebird делает то же самое. Однако необходимость "прямого" доступа к серверу из драйвера объясняется например невозможностью (либо спецификой) использования gds32.dll при работе с виртуальной машиной. Собственно, вас такие особенности волновать не должны - если вы пишете приложения для .Net, то у вас выбор драйверов (и их типов) ограничен как раз спецификой .Net, а уж как этот драйвер общается с сервером - не имеет никакого значения (этим озабочены разработчики драйвера).

! Не нужно бросаться сразу читать API Guide и писать на IB API - это совершенно ни к чему. Скорее всего вам нужны какие-либо из нижеперечисленных готовых компонент.

От клиента к серверу и обратно

Чтобы было более понятно, упоминаются драйверы, компоненты и клиентские части как InterBase/Firebird, так и Oracle

BDE

Примерно в 2002 году еще компания Borland (ныне Embarcadero) объявила о том, что больше не собирается развивать BDE. Тем не менее, он до сих пор поставляется в Delphi и C++Builder для обеспечения совместимости со старыми приложениями. Сейчас использовать BDE для работы с SQL-серверами не рекомендуется. Embarcadero вместо BDE для универсального доступа к разным СУБД продвигает свои компоненты и драйверы dbExpress (см. дальше).

Приложение -> BDE (IDAPI32.DLL) -> SQLINT32.DLL -> GDS32.DLL ........... Server InterBase/Firebird
                                   SQLORA32.DLL -> ...dll    ........... Server Oracle
                                   IDODBC32.DLL -> Any ODBC Driver ..... Any Server
                                   IDPDX32.DLL  -> Paradox File

ODBC

ODBC известный способ доступа к СУБД от Microsoft, и может использоваться везде. ODBC-драйверов много, см. перечень.

Приложение -> ODBC API -> InterBase/Firebird ODBC Driver     -> GDS32.DLL .... Server InterBase/Firebird
                          Oracle ODBC Driver 				-> OCI.DLL   .... Server Oracle

ADO

Если вы пишете приложения в Delphi и C++Builder, и работаете с InterBase или Firebird, то использование ADO будет оправдано только тем, что вы привыкли к ADO или из этого приложения надо работать как с MS SQL, так и с другими СУБД. В остальных случаях ADO с InterBase/Firebird лучше не использовать, т.к. есть более прямые пути (компоненты) доступа.

Приложение -> ADO компоненты->   ODBC          -> GDS32.DLL .... Server InterBase/Firebird
								-> IBProvider    -> GDS32.DLL .... Server InterBase/Firebird
							   	 -> Oracle OLEDB  -> OCI.DLL   .... Server Oracle
								 -> MS OLEDB      -> ...       .... MS SQL

dbExpress

Приложение -> dbX API -> InterBase dbX Driver      -> GDS32.DLL .... Server InterBase/Firebird
                         Firebird dbX Driver-> fbclient.dll .... Server InterBase/Firebird
                         UIB dbX Driver     -> GDS32.DLL .... Server InterBase/Firebird
                         Upscene dbX Driver -> GDS32.DLL .... Server InterBase/Firebird
                         Oracle dbX Driver  -> OCI.DLL   .... Server Oracle

.Net

Приложение -> BDP           -> InterBase BDP Driver              ?        .... Server InterBase/Firebird
                            -> Firebird BDP Driver                 .... Server Firebird
                            -> Oracle BDP Driver          ?        .... Server Oracle
              ADO.Net       -> Firebird .Net                       .... Server InterBase/Firebird
                            -> IBProvider         -> gds32.dll ->  .... Server InterBase/Firebird
                            -> ODP.Net                             .... Server Oracle
              OLE DB        -> IBProvider         -> gds32.dll ->  .... Server InterBase/Firebird
              BDE.Net       -> ...
              dbExpress.Net -> ...

Java

Приложение -> InterClient Type 3         -> GDS32.DLL  .... Server InterBase/Firebird
           -> InterClient Type 4                       .... Server InterBase/Firebird
           -> Firebird JCA/JDBC Driver                 .... Server InterBase/Firebird

Прямой доступ (без промежуточных драйверов, через клиентскую часть)

Приложение - > IBX       -> GDS32.DLL       .... Server InterBase/Firebird
               FIBPlus   -> GDS32.DLL       .... Server InterBase/Firebird
               UIB       -> GDS32.DLL       ....
               IBObjects -> ...   
               ODAC      -> OCI.DLL         .... Server Oracle
               DOA       -> OCI.DLL         ....

Переносимость и портирумость

Причем, понятно что везде - Java, прямые компоненты, .Net и прочее имеют свои интерфейсы к так называемым DataSet. Например, в dbExpress, .Net и т.п. как такового (эквивалентного BDEDataSet, IBDataSet, pFIBDataSet и т.п.) DataSet нет - в них данные выбираются в ClientDataSet, который работает совершенно по другому, и кстати может быть использован совместно с DataSet любого типа.
Дальше, в .Net "курсор" называется SQLCursor, а в ADO.Net - IDataReader.

Таким образом, налицо тотальная несовместимость. Выглядит это все, конечно, очень похоже, и методика работы например с dbExpress и ADO.Net также похожа, но понятно, что это несовместимо на уровне имен классов/компонент и их методов.

В .Net с компонентами прямого доступа, в отличие от всяческих драйверов, ситуация такая - VCL.Net поддерживает возможность обращения к gds32.dll через Windows InteropServices (VCL.Net сгинул примерно в 2007 году. Аминь). То есть, если требуется обеспечить переносимость (или совместимость) приложения, написанного на IBX под D7 на .Net, то нужна будет измененная версия IBX, в которой вся работа по распределению памяти, типам, указателям и т.п. приведена в соответствие с требованиями портируемости Win32->.Net.
То есть, до тех пор, пока не будет портированного на .Net FIBPlus, DOA, ODAC и т.п. - осуществить перенос приложений с Win32 на .Net не удастся.

Конечно, не стоит забывать что Delphi 2005-2010 это не "обновление D8" в самом узком смысле. Delphi 2005-2006 это не только программирование под .Net, но и полноценное программирование для Win32. Например, в Delphi 2005-2009 входит обычный (win32) IBX.

примечание: начиная с Delphi 2007 поддержка .Net вынесена в отдельные продукты. Сейчас это Delphi Prism. В Delphi же оставлена возможность компиляции только приложений для Win32.

Там, где выбора нет

Что касается web-программирования с использованием PHP и тому подобных движков, то тут все и так совершенно ясно. Например, PHP самостоятельно работает с клиентской библиотекой gds32.dll. Если надо Perl, то тут поможет DBD:Interbase, и ничего более. И т.д., и т.п.

Убогие

Функционал IBX, FIBPlus, IBObjects сомнению не подлежит - он широк настолько, насколько это позволяет IB/FB API, т.е. gds32.dll/fbclient.dll. Дальше начинается урезание - BDE, мог в одном соединении давать работать только с одной явной транзакцией. dbExpress в этом плане получше, но в нем нельзя указыва специфические параметры транзакций, такие как read read_committed или резервирование таблиц. ODBC сам по себе тоже, избытком функциональности не страдает, хотя драйверы EasySoft и Gemini целиком и полностью соответствуют спецификации ODBC 3.51, что позволяет работать с IB/FB практически из любых готовых приложений (тот же MS Office или что угодно). IBProvider - тоже вне сомнений, причем используя его как промежуточную прослойку можно работать и с компонентами ADO, но скорее всего этот вариант не даст использовать функционал IBProvider целиком.

Остальные библиотеки прямого доступа (не ODBC, dbExpress и т.п.) написаны в расчете на универсальность в том смысле, что эти библиотеки являются наименьшим общим знаменателем для кучи SQL-серверов. Это Zeos, SQLDirect, SQLRoots и т.п. Конечно, использовать такие библиотеки можно, но только в том случае, если вы считаете их более функциональными чем dbExpress, а также если есть настоятельная потребность работать с IB, Oracle, MS SQL и т.п. одним и тем же кодом. В отличие от dbExpress, наличие портируемых вариантов этих библиотек находится под большим вопросом.

Особняком из примитивных библиотек стоит UIB. Как было показано выше, это не только набор компонент, но и еще драйвер dbExpress. Для сугубо серверных приложений - отличный выбор.

Итого

Кроме упомянутых критериев выбора существует еще один - платность (или бесплатность) конкретной библиотеки. Использовать "халявный" IBX, или платный FIBPlus? Базовый dbExpress-драйвер или платный от Upscene? На начальном этапе, конечно, вы не сможете оценить отличия платной от бесплатной версии (если только конкретная библиотека/драйвер не существует в единственном варианте). Послушайте коллег, попробуйте, в конце-концов, условно-бесплатные версии. Как минимум, платные библиотеки/драйверы, особенно разрабатываемые в России, содержат меньше ошибок, а если и содержат - очень быстро исправляются.

Если же вас интересует статистика, то 60-70% приложений пишутся с использованием IBX и FIBPlus (примерно поровну). Оставшиеся 40-30% - BDE, IBObjects, ODBC и все остальное.

Вот такие пироги.

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