Форум на Исходниках.RU https://forum.sources.ru Форум на Исходниках.RU Форум на Исходниках.RU https://forum.sources.ru/index.php?showtopic=44239&view=findpost&p=289651 Thu, 29 Jan 2004 13:02:31 +0000 ODBC & *NIX https://forum.sources.ru/index.php?showtopic=44239&view=findpost&p=289651 M$-технологий... то, что получилось, я "свел" в этом постинге.

ВНИМАНИЕ! Не стоит пытаться подстрелить меня из рогатки с оптическим прицелом и глушителем.
Я ПРЕКРАСНО знаю, что работа с файлом от M$ Access средствами ODBC -- бред, т.к.
файл Access'а относится к ISAM-файлам (Index-Sequence Access Method), для работы с которыми есть
все-таки технология DAO (Data-Base Access Objects) от того же M$, но... Ну нет у меня "под рукой" M$ SQL
Server'а, а ставить -- а не ну ли его на фиг? Чтобы потом "сносить"? Вот и тестировал на том, что было.

Хэх! Как верно заметил Olej в одном из своих постингов, работа с ODBC из UNIX -- только для тех,
"кто понимает толк в истинных извращениях". Добавлю от себя что и вообщем-то ODBC, даже в M$ Windows
никогда не были самым удобным интерфейсом, ни в С, ни, тем более, в С++. Хотя, справедливости
ради, надо заметить, что все остальное (в том числе и основанное на ODBC) -- еще хуже, т.к. ODBC
(по крайней мере, если прочесть именно о самой идее ODBC), еще более-менее "прозрачный" интерфейс.
И учесть довольно "малоглюкавую" реализацию, что для M$, согласитесь, отнюдь не типично. Хотя, подчас
работать с ODBC -- "истинное удовольствие"...

Как пример UNIX'овского подхода к делу, могу привести практически любую БД под UNIX (от Oracle до
PostgreSQL и SAP DB), в которых считается правилом хорошего тона предоставлять не один, а ряд инструментов:
- это и библиотеки доступа к БД, основанные на "Embedded SQL". В этом случае Вы пишете некий "промежуточный"
код из SQL и С, "скармливаете" его препроцессору из состава БД и на выходе получаете С-модуль, реализующий
SQL-запросы к БД по Вашей "спецификации".
- Это и библиотеки "прямого доступа" к данным для БД...
- Библиотеки работают как с С, так и с С++, Perl, Java... Собственно, можно делать что угодно, как угодно
и при помощи каких угодно инструментальных средств.

Да, собственно, много чего есть в UNIX для работы с БД. По этой причине, человеку, пришедшему из
мира Windows, можно слегка ошалеть, только прочитав документацию на нормальную БД.

Ладно. Что нам-то делать? Т.к. глюки глюками, а доступ к тому, что M$ называет "базами данных" все-таки
надобно поиметь.

Вариант #1 -- iODBC.
Поддерживается ряд платформ:
     
        SunOS       4.1.x       Sun Sparc
        HP/UX       9.x, 10.x   HP9000 s700/s800
        HP/UX       9.x         HP9000 s300/s400        
        IBM AIX     3.x, 4.x    IBM RS6000, PowerPC
        Sun Solaris 2.x     Sun Sparc, PCx86
        SGI Irix SVR4   5.x, 6.x    IP12 MIPS, IP22 MIPS
        NCR SVR4    3.x     NCR 3435
        UnixWare SVR4.2 1.x, 2.x    x86
        DEC Unix(OSF/1) 3.x, 4.x    DEC Alpha
        FreeBSD     2.x     x86
        BSDI BSD/OS     2.x     ?
        Linux ELF   1.2.x, 1.3.x    x86
        SCO OpenServer  5.x         x86
        Max/OS SVR4 1.x     Concurrent Maxion 9200 MP
        DG/UX       5.x     Aviion
        OpenVMS     6.x     DEC Alpha
        Windows NT  4.x     x86


Как работает.
Так же как и ODBC в "чистом виде". Есть некий промежуточный слой, к которому обращается прикладная программа.
Через этот слой идет обращение к "драйверу БД", который транслирует SQL-запрос серверу БД. Сервер БД чего-то
делает и возвращает результаты по обратной цепочке. Драйвера к той или иной БД представляют собой библиотеки.

Все бы было хорошо, еслиб не было так плохо. Проблема в драйверах. Дело в том, что та "контора", которая
разработала все это дело, разрабатывает и драйвера для БД, причем, "кросс-платформенные". И распространяет
их на коммерческой основе. Хотя, в принципе, демо-версии дров получить можно и, вроде, даже во времени они
не ограничены, но, по-моему, с функциональностью у них есть некоторые "напряги". По крайней мере, драйвер
для M$ Access слегка кривоват. Или мне просто показалось... Ничего не собираюсь утверждать.

Дополнительные ссылки:
- http://www.iodbc.org -- сам по себе проект.
- http://www.openlinksw.com -- драйвера, распространыемые на коммерческой основе.

Минусы -- самый, пожалуй главный -- проблема с дровами. Второй "минус" -- рекомендуется править файл
~/odbc.ini "врукопашную". Нет, не то, что бы я был против... Но... Есть вариант и по-лучше...
Уж "развлекаться", так по полной... :D

Вариант #2 -- unixODBC.
Поддерживается весь тот же ряд платформ, но, плюс еще и QNX.

Как работает.
Все точно так же, как и предыдущий вариант -- за исключением одного "но" -- для доступа к БД, расположенным
под Windows, Вам понадобится "мост" ODBC-ODBC. Т.е. этот мост становится в unixODBC "универсальным драйвером"
БД, к которому идет обращение со стороны "промежуточного слоя ODBC" за данными, о которых известно, что они
расположены под Win32.

Если данные расположены под UNIX, то unixODBC работает через свои драйверы. Т.е. unixODBC привносит в UNIX
методику работы с БД из Win32. Этому уродству есть только одно объяснение. IMHO, если софтина должна
работать с данными как под Win32, так и под UNIX, то проще в этой софтине использовать пусть и корявый, но
единый интерфейс, нежели развлекаться с двумя вариантами.

Дополнительные ссылки:
- http://www.easysoft.com -- менеджер для unixODBC и "мост" ODBC-ODBC. Последний -- trial 30-day edition.
- http://sourceforge.net/projects/unixodbc/ -- AS IS.
- http://www.unixodbc.org/

Минусы -- все то же желание разработчиков получить с нас денежку, но это, IMHO, не всегда и плохо. Но здесь,
IMHO, налицо случай явного и принудительного инфицирования разработчиков "зеленой лихорадкой" имени Гейтса.

Плюсы -- большая открытость и продуманность как интерфейса и средств управления, так и драйверов, к примеру,
есть драйвера для Internet News Server. Есть шаблон драйвера (для желающих). Видел драйвер для InterBase.
К этой "базе данных" у меня особотрепетное отношение. Когда-то программисты в той конторе, где я работал
админом, на голой груди все волосы голыми руками по-вырывали за этот IB. Дело кончилось переходом на M$ SQL.

Далее. Есть, правда консольное, но средство построения sql-запросов к ресурсам, определенным в ~/odbc.ini.
Позволяет довольно быстро и качественно конструировать запросы. Вполне возможно русифицировать "конфигураторы"
"источников данных" -- я про DataManager'ы и ODBCConfig. Они писаны на С++, с применением Qt (KDE).

Как выглядит прога, использующая *ODBC?
Да как почти обычное Win32 С-приложение, с ТакимЖеВотСинтаксисом. С теми же SQLExec(...), SQLAllocStmt(...),
SQLFreeStmt(...) и т.д. и т.п., т.к. сами по себе средства *ODBC ничего не стараются менять в исходном тексте,
портируемом из Win32. Библиотеки есть для С и С++. Так что, если есть опыт развлечений с ODBC в Windows и
рука не дрогнет "отслюнить" какие-то деньги за софт под *NIX, то... Вам виднее...

Сейчас вот перечитал написаное -- может, все-таки WinE использовать? В любом случае, лично мне не очень
понравились ни первый ни второй варианты. Буду пробовать. А пока, скажем так, "затычка" для задачи есть. IMHO,
за тридцать-то дней чего-нибудь придумаю... Хотя, может, у кого какие идеи есть?]]> the_Shadow *nix