Когда следует использовать хранимые процедуры Java с базой данных Oracle... каковы недостатки?

Ответ 1

В мире Oracle общий порядок развития должен быть:

По возможности сделайте это чисто с SQL. Если вам нужно больше, чем SQL, сделайте это с помощью PL/SQL. Если вам нужно что-то, что PL/SQL не может сделать, используйте Java. Если все остальное не удается использовать C. Если вы не можете сделать это с помощью C, медленно отходите от проблемы....

Хранимые процедуры PL/SQL - отличный способ переноса вашей бизнес-логики на уровень, доступный любой из технологий интеграции. Бизнес-логика в пакете (не писать автономные функции и процедуры - они будут расти со временем неуправляемым способом) могут выполняться Java, С#, PL/SQL, ODBC и т.д.

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

Хранимые процедуры Java лучше всего подходят для создания функциональных возможностей, взаимодействующих с сетью или операционной системой. Примерами могут быть: отправка электронных писем, передача данных по FTP, вывод в текстовые файлы и их замена, выполнение команд командной строки в целом.

Мне никогда не приходилось кодировать C во время работы с Oracle, но, вероятно, его можно было использовать для интеграции с устаревшими приложениями.

Ответ 2

Только если вы не можете сделать это в PL/SQL (или PL/SQL оказывается слишком медленным, что было бы довольно редко, я верю).

В качестве примера... У нас была одна хранимая процедура java, работающая в производстве (Oracle 9i), она была первоначально написана в java, потому что в то время, когда мы думали, что Java классный, что-то, что я давно изменил около. Так или иначе. Однажды, DB сбой, после перезагрузки java SP не работает. После многого назад и вперед с поддержкой оракула, они действительно не знают, в чем проблема, и единственные предложения, которые у них связаны с большим временем простоя. Что-то, что не было вариантом. Через 30 минут я переписал java SP в PL/SQL.

Теперь он работает быстрее, оракул "родной", использует тот же процесс развертывания, что и другие объекты, и его легче отлаживать.

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

Ответ 3

Основным преимуществом является доступ к API и языковым функциям, не найденным в PL/SQL. Например, я использовал их для обработки регулярных выражений, манипулирования файлами/каталогами и анализа XML.

Существует ряд недостатков:

• Плохая поддержка инструмента
• Отсутствие контроля над JVM
• DBA часто не обучаются Java. Чтобы поддержать ваш производственный код, вам нужно либо предоставить вашему DBA больше обучения, либо нанять персонал, прошедший подготовку по Java

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

Вам определенно нужна причина использовать Java в базе данных над: a) хранимыми процедурами PL/SQL или b) Java за пределами базы данных.

Ответ 4

Java позволяет писать код нейтральной базы данных. Это позволяет повторно использовать существующий код и значительно повысить производительность.

Одна вещь, которую я нахожу в Java Хранимые процедуры, полезной для File IO. Java имеет гораздо более богатый набор возможностей File IO, позволяя разработчикам удалять файлы, добавлять каталоги и т.д. По сравнению с пакетом Oracle UTL_FILE.

Ответ 5

Я использовал Oracle emmbedded java для двух проблем:

1) Выполнять процедуру PLSQL, которая заполняет результаты запроса в текстовом файле и передает его по FTP. Этот файл был очень большой, и я использую Java для его Zip.

2) В приложении клиент-сервер с прямым соединением с БД, чтобы сравнить пароль, отправленный пользователем (не пароль пользователя БД), хэшированный с MD5, чтобы пароль не перемещался сетью в виде обычного текста, Я не уверен, было ли это лучшим решением для этой проблемы, я сейчас попрошу об этом.:)

Ответ 6

<сильные > Преимущества:

• Можно использовать идентичную логику приложения в клиенте и базе данных
• Доступ к API Java. Следите за тем, какая версия java поддерживается каждой базой данных. Я считаю, что 10g поддерживает только 1.4 (что означает, что в моей работе мы должны быть очень осторожны, так как наша основная база кода недавно переместилась на 1.5).

Недостатки:

• Java-хранимые процедуры, выполняющие много доступа к базе данных, могут быть довольно медленными.
• Сложнее развернуть код

Ответ 7

Используйте Java, когда вы абсолютно не можете сделать это в PL/SQL, или, если Java позволит вам повысить производительность.

В качестве примера, если вы хотите использовать сокеты в программе PL/SQL (ведение журнала, внешние вызовы и т.д.), вы можете:

• напишите PL/SQL-клиент, который использует UTL_TCP. Невозможно выполнить UDP, используя только собственный PL/SQL.
• напишите клиент Java, который использует сокеты TCP или UDP.

В первом случае у вас есть синхронный сокет, который может создавать резервные копии ваших вызовов PL/SQL, если у удаленной службы есть проблемы. Кроме того, если вы используете dbms_session.reset_package (как в OWA), вам придется подключать сокет для каждого запроса, что очень дорого.

Во втором случае TCP по-прежнему является синхронным, но если вам нужно асинхронное, неблокирующее поведение, вы можете использовать UDP. Кроме того, reset_package не поддерживает reset Java TCP или UDP-сокеты, поэтому вам не придется иметь дело с болью срыва/повторного соединения.

Ответ 8

Ответ НИКОГДА. Если вам нужно писать программы для загрузки или обработки данных, вам необходимо сделать это за пределами своего уровня данных с другого компьютера в сети.

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