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

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

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

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

PL/SQL — это самый быстрый способ перебрасывать огромные куски данных вне чистого SQL. Функции «массового связывания» означают, что он очень хорошо работает с механизмом SQL.

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

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

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

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

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

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

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

Есть ряд недостатков:

• Poor tool support
• Lack of control over the JVM
• DBA's often aren't trained in Java. In order to support your production code you'll either either need to give your DBA's more training or hire Java-trained support staff

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

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

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

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

Преимущества:

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

Недостатки:

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

Я использовал встроенную Java для Oracle для двух проблем:

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

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

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

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

1. написать клиент PL/SQL, использующий UTL_TCP. Однако нет никакого способа сделать UDP, используя только родной PL/SQL.
2. напишите клиент Java, который использует сокеты TCP или UDP.

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

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

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

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