java - stored - procedimientos almacenados mysql

¿Cuándo debería usar los procedimientos almacenados de Java con una base de datos Oracle... cuáles son los inconvenientes? (8)

PL / SQL no es mi lengua materna. Oracle admite la escritura de procedimientos almacenados en Java. ¿Cuáles son las ventajas de hacer esto antes de escribir los procedimientos almacenados en PL / SQL?

La respuesta es NUNCA . Si necesita escribir programas para cargar o procesar datos, debe hacerlo fuera de su nivel de datos desde otra computadora en la red.

Ejecutar aplicaciones externas directamente en su nivel de datos o permitir que Dios entre en proceso con su nivel de datos o la aplicación incorrecta de idiomas externos cuando los lenguajes de consulta nativos se ajustan mejor al trabajo en cuestión son buenos y perfectamente aceptables para una pequeña escala personalizada interna solicitud. Simplemente no tienen lugar fuera de esa arena.

En el mundo de Oracle, el orden general de desarrollo debería ser:

Siempre que sea posible, hazlo puramente con SQL. Si necesita más que SQL, hágalo con PL / SQL. Si necesita algo que PL / SQL no puede hacer, entonces use Java. Si todo lo demás falla, use C. Si no puede hacerlo con C, retroceda lentamente alejándose del problema ...

Los procedimientos almacenados de PL / SQL son una forma excelente de trasladar su lógica de negocios a una capa a la que cualquier tecnología de integración pueda acceder. Lógica empresarial en un paquete (no escriba funciones y procedimientos independientes: crecerán con el tiempo de una forma inmanejable) pueden ser ejecutados por Java, C #, PL / SQL, ODBC, etc.

PL / SQL es la forma más rápida de arrojar grandes cantidades de datos fuera de SQL puro. Las características "Bulk Binding" significa que funciona muy bien con el motor SQL.

Los procedimientos almacenados de Java son los mejores para crear una funcionalidad que interactúa con la red o el sistema operativo. Algunos ejemplos serían, enviar correos electrónicos, enviar datos por FTP, enviarlos a archivos de texto y comprimirlos, ejecutando líneas de comando de host en general.

Nunca tuve que codificar C al trabajar con Oracle, pero es de suponer que podría usarse para integrarse con aplicaciones heredadas.

He utilizado Oracle emsamblado Java para dos problemas:

1) Para hacer un procedimiento PLSQL que agrega los resultados de una consulta en un archivo de texto y lo envía a través de FTP. Este archivo era muy grande y uso Java para Zip.

2) En una aplicación cliente-servidor con conexión directa con el DB, para comparar la contraseña enviada por el usuario a la aplicación (no la contraseña del usuario DB) hash con MD5, para que la contraseña no viaje por la red en texto plano. No estoy seguro de si esta era la mejor solución para este problema, voy a preguntar ahora. :)

Java hace posible escribir código de base de datos neutral. Le permite reutilizar el código existente y aumentar drásticamente la productividad.

Una cosa que encuentro útil para los procedimientos almacenados de Java es File IO. Java tiene un conjunto mucho más rico de capacidades File IO, lo que permite a los desarrolladores eliminar archivos, agregar directorios, etc., en comparación con el paquete UTL_FILE de Oracle.

La principal ventaja es el acceso a las características de API y lenguaje que no se encuentran en PL / SQL. Por ejemplo, los he usado para el procesamiento de expresiones regulares, la manipulación de archivos / directorios y el análisis de XML.

Hay una serie de desventajas:

Pobre soporte de herramienta
Falta de control sobre la JVM
Los DBA a menudo no están entrenados en Java. Para respaldar su código de producción, o bien deberá brindar más capacitación a su DBA o bien contratar personal de soporte capacitado en Java.

Mover el Java a un servidor de aplicaciones es a menudo un mejor enfoque ya que contrarresta las desventajas. Existe un excelente soporte de herramientas, un gran control sobre la JVM y hay montones de personas capacitadas en los populares servidores de aplicaciones, por lo que resulta fácil encontrar personal de soporte. Existe el costo de oportunidad del impacto en el rendimiento que se aleja de la base de datos, pero mantener Java cerca de la base de datos no le da grandes ganancias de rendimiento de todos modos.

Definitivamente necesita una razón para usar Java en la base de datos sobre a) procedimientos almacenados PL / SQL ob) Java fuera de la base de datos.

Solo cuando no puede hacerlo en PL / SQL (o PL / SQL demuestra ser demasiado lento, lo cual sería bastante raro, creo).

Como caso de estudio ... Tuvimos un solo procedimiento almacenado en java que se ejecuta en producción (Oracle 9i), originalmente fue escrito en Java porque en ese momento pensamos que Java era genial, algo que hace mucho tiempo que he cambiado de opinión. De todas formas. Un día, el DB se bloquea, después de que se reinicia el java SP no funciona. Después de mucho ir y venir con soporte Oracle, realmente no saben cuál es el problema y las únicas sugerencias que tienen implican mucho tiempo de inactividad. Algo que no era una opción. 30 minutos después, reescribí el java SP en PL / SQL.

Ahora funciona más rápido, es oráculo "nativo", comparte el mismo proceso de implementación que otros objetos y es más fácil de depurar.

PL / SQL es un lenguaje muy capaz. Si está escribiendo Procedimientos almacenados, tómese el tiempo para aprenderlo en lugar de simplemente hacer cosas en Java porque eso es lo que sabe.

Ventajas:

Puede compartir lógica de aplicación idéntica en el cliente y la base de datos
Acceso a la API de Java Tenga cuidado con la versión de Java que admite cada base de datos. Creo que 10g solo admite 1.4 (lo que significa que en mi trabajo debemos ser muy cuidadosos ya que nuestra base de código principal se ha movido recientemente a 1.5).

Desventajas:

Los procedimientos almacenados de Java que hacen un montón de acceso a la base de datos pueden ser bastante lentos
Más difícil de implementar su código

Use Java cuando absolutamente no puede hacerlo en PL / SQL, o si Java le permitirá un mayor rendimiento.

Como ejemplo, si desea utilizar sockets dentro de un programa PL / SQL (registro, llamadas externas, etc.), puede:

escriba un cliente PL / SQL que use UTL_TCP. Sin embargo, no hay forma de hacer UDP usando solo PL / SQL nativo.
escriba un cliente Java que use sockets TCP o UDP.

En el primer caso, tiene un socket síncrono que puede respaldar sus llamadas PL / SQL si el servicio remoto tiene problemas. Además, si está utilizando dbms_session.reset_package (como en OWA), tendrá que volver a conectar el socket para cada solicitud, que es muy costoso.

En el segundo caso, TCP sigue siendo síncrono, pero si necesita un comportamiento asincrónico sin bloqueo, puede usar UDP. Además, reset_package no restablece los sockets TCP o UDP de Java, por lo que no tendrá que lidiar con el problema de reducción / reconexión.