Java Stored Procedure в субд Oracle на примере формирования PDF-файла

[norguhtar]

Завязывайте с тяжелыми наркотиками.

[astamur]

Можно более подробно?

[norguhtar]

[astamur]

Ну и что не так в данной конкретной ситуации?
PDF-файл открываю, редактирую и сохраняю просто для примера. В Ява-классе можно какой-нибудь другой функционал реализовать. Я постарался описать сам процесс создания Java Stored Procedures. Конечно, я затронул далеко не все моменты, но все же.

[norguhtar]

Ну и что не так в данной конкретной ситуации?

Плохой пример. Хранимые процедуры так использовать точно не стоит.

[astamur]

Хранимые процедуры так использовать точно не стоит.

В том смысле, что я файл на сервере сохраняю?

[norguhtar]

В том смысле что вы файл хранимой процедуры в СУБД сохраняете, не надо так.

[ztxn]

Можете объяснить почему?

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

[norguhtar]

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

[ztxn]

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

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

[norguhtar]

Лучше — чем? Тем, что появляется еще одно звено системы — выделенный сервер, который нужно ставить на мониторинг, поддерживать, воспроизводить на тестовых окружениях, учитывать при планировании переездов?

Рассказываю страшную тайну. У вас такой сервер есть и и он использует эту СУБД уже и так. Сама по себе СУБД без приложений которые его используют смысла не имеет.

Да, идея организации репортинга на стороне СУБД сомнительна. Но если это затевается для одного, двух, пяти отчетов лишь — идея выделения под то обособленного звена тоже вылядит как бы не совсем блестяще.

Один два отчета проще выгружать штатным клиентом в csv.

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

Хранимку сколько угодно. Выше описка должно быть:

В том смысле что вы файл из хранимой процедуры в СУБД сохраняете, не надо так.

[ztxn]

Выше описка должно быть

Понял, спасибо.

[astamur]

Да, согласен с вами. Идея создавать отчеты через хп на сервере СУБД — далеко не фонтан. Сам пример выбран не удачно. Больше хотел само создание java хп показать, а для примера взял первое, что под руку попало. Извиняюсь, но какая хорошая дискуссия за то вышла))

[VoVanJinn]

А чего там смотреть то:
Class.forName(«oracle.jdbc.driver.OracleDriver»).newInstance();
Connection connection = DriverManager.getConnection(«jdbc:default:connection:»);
И ка-ак давай jdbc-ячить направо и налево.

[btd]

И ка-ак давай jdbc-ячить направо и налево.

Как же мне нравится русский язык =)

[ForNeVeR]

А там что, нету каких-нибудь специализированных способов доступа к данным, например, с использованием текущей транзакции? В чём тогда преимущества таких процедур? Мне всегда казалось, что их используют, когда хочется получить преимущества полноценного языка программирования, но не потерять преимуществ высокой скорости обработки данных, изоляции транзакций и выражений на сервере SQL. Я ошибался?

[xtender]

специализированных способов доступа к данным, например, с использованием текущей транзакции

все есть, так и работает. наоборот, чтобы быть не в текущей транзакции нужно шагнуть влево