Pull to refresh

Comments 11

По заголовку в принципе было понятно, что будут страдания, но что настолько - я, честно говоря, не ожидал. Ладно бы статься была из 1995, тогда это вот всё, да. Но в 2021? Как research проект - может быть. Как решение реальной задачи - КМК overhead 146% по времени разработки и поддержки. Тем более, что в целевых системах - только свежая винда, ограничений по аппаратным ресурсам явно нет. Я не специалист в .Net, но вроде там какая-та версия библиотек прямо вместе с ОС ставится, т.е. собираете небольшой .exe на C# и ага, задача решена. Вариантов выстрелить в ногу в разы меньше будет. Можно вообще сразу посмотреть в сторону GraalVM / Java, там нативный образ из коробки будет и не только под винду, и даже OCI не потребуется - в JDBC уже есть всё, что нужно.

Не совсем, все-таки потребуется установка провайдера Oracle для dotNet или Java, есть даже "тонкие" провайдеры без зависимостей от клиента Oracle, но там к базе надо будет соединяется с полным текстом дескриптора (см. содержимое файла sqlnet.ora). Но в остальном да, с C# всё намного проще и быстрее.

Для Java не потребуется. Потребуется ojdbc-что-нибудь.jar для сборки, но он потом будет в образе лежать, который fat jar. Полный текст дескриптора нужен как рыбе зонтик, достаточно ip или доменного имени сервера, порта и SID. Если немного заморочиться, эти данные можно в коде программы добыть прямо из sqlnet.ora на целевой машине, благо известно, где его искать. Там много чего становится сразу можно :)

Ряд требований я специально опустил, чтобы не загромождать статью лишней информацией, но ситуация была такова:
1) Утилитой должна быть удобна для использования не админами и не разработчиками - то есть у нее должен быть графический интерфейс.
2) Оракл обычно ассоциируется с кровавым энтерпрайзом - безумные бюджеты, терабайты оперативной памяти и прочее. У нас ситуация в этом смысле нестандартная: клиенты - бюджетные организации, где все еще встречаются сервера с 4 ГБ оперативки, на котором расположен и сервер БД и сервер приложений. Скромность в потреблении ресурсов имела большое значение.
3) Есть в нашей стране уголки, где проблемы с интернетом. Либо очень маленькая скорость, либо нестабильный линк, либо и то и другое. Размер исполняемого файла был немаловажным требованием.
4) В У очень многих наших клиентов нет штатных админов и получить доступ на сервер для работ - тот еще квест. (скриншот ТимВьювера в вордовском документе - наше все)
Отсюда и вытекают ограничения, которые были поставлены еще на этапе проектирования.
- .Net не желателен, так как требует перезагрузки. Ну и скачать его тоже не везде будет просто.
- Java - очень хороший вариант, так как у нас есть штатные разработчики и мне вообще не пришлось бы писать это)) Но минусы тут - у некоторых клиентов скачка 100 МБ для JRE - это час-другой. Плюс 100-200 МБ оперативки, которую утилитка сразу себе потребует могут быть непозволительной роскошью))

Поэтому и пришлось писать именно так. Пара лет использования показали, что усилия были не напрасны

Работать утилита должна на любом компьютере с ОС Windows выше Windows 7 или Windows Server 2008 без установки каких-либо фреймворков и Runtime Environment. Должен быть установлен только какой-то из продуктов Oracle, включающий OCI-библиотеку.

Кажется, сейчас разобраться с каким-либо популярным в текущий момент "упаковщиком всего нужного в один бинарник" для "вашего любимого инструмента разработки" проще и выгоднее (по затрате усилий), чем писать клиентские приложения для OracleDB на C/C++
И не могу промолчать уходя немного в оффтопик: довелось длительное время (лет 10, наверное) внедрять и сопровождать продукт, у которого в качестве базы данных Oracle DB, и на фоне вот того опыта, слова "должен быть какой-то из продуктов Oracle, включающий OCI", у меня вызывают нервный смех. Прекратил всего этого касаться я когда еще не перешли целиком на 12c, а только присматривались. У версий 10 и 11, с вот этим все очень-очень-очень всё непросто, и может быть множество разных неожиданных фокусов даже если у сервера базы и клиента разные patch level. Другими словами, я не верю, что в реальной жизни можно полностью исключить какую-либо установку чего-либо из продуктов Oracle на компьютер с клиентским приложением. В тоже время, могу легко представить, что есть четки процедуры развертывания/обновления клиентских мест, но тогда известен набор "что должно быть точно", и опять-же, гораздо эффективнее, расширить этот набор, добавив требуемые библиотеки, а утилиты разрабатывать используя удобные инструменты.

Я выше ответил на вопрос, зачем были эти страдания)

По поводу вашего оффтопика - да, вы правы, просто в нашей ситуации на машинах, на которых предполагалось использование этой утилиты, уже должны быть установлены либо соответствующая версия СУБД, либо соответствующая версия OracleClient. Так что такой проблемы не стояло

Плюс всегда можно поставлять эту утилиту с нужной версией Oracle Instant Client - тогда никаких установок не нужно

>другими словами, я не верю, что в реальной жизни можно полностью исключить какую-либо установку чего-либо из продуктов Oracle на компьютер с клиентским приложением.
Ну JDBC например не требует установки. Вам возможно потребуется Java, чтобы приложение запустить, но она тоже не требует установки, и можно быть принесена с собой. В теории потребуется обновлять иногда драйвер, так как скажем драйвер от 12 версии не будет уметь что-то делать из того, что появилось в 19-й — но это уже зависит от функций приложения, от того, какую версию СУБД оно ожидает.

Самое неприятное с работой с ораклом из сишного кода с Pro C насколько я помню, что нужно явно перечислять все поля и иметь сишную структурку данных, которая эти поля отражает, что доставляет чутка дискомфорта если например нужно сделать select * ... из таблички с парой сотен полей :)

Спасибо за статью, будет полезна.

Хотелось бы услышать по подробнее по саму задачу. Возможно это можно решить все проще, например так:

Ставь oracle клиент вообще не обязательно, можно просто скачать oracle instant client - он занимает около 30 мб и не требует и установки, в комплекте и oci, и sqlplus.exe. а при желание наверно можно уменьшить и до 10 мб.

С другой стороны имея sqlplus.exe, то C++ особо не нужен, достаточно будет написать скрипт на pl/sql который будет исполняться на клиенте (посредством sqlplus) и работать с oracle db.

Если нужны специфичные от ос функции, у вас всегда есть под рукой powershell, либо wsh+wmi

Если подумать то все это должно быть не больше 20..30 мб и все это замечательно можно упаковать zip/rar/7z sfx

Ставь oracle клиент вообще не обязательно, можно просто скачать oracle instant client

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

С другой стороны имея sqlplus.exe, то C++ особо не нужен, достаточно будет написать скрипт на pl/sql который будет исполняться на клиенте (посредством sqlplus) и работать с oracle db.

Нет, в утилите используется ряд действий, которые не выполнить скриптом - например передача бинарных данных большого размера.

Если нужны специфичные от ос функции, у вас всегда есть под рукой powershell, либо wsh+wmi

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

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

Sign up to leave a comment.

Articles