Cómo llamar a código Java desde MySQL?

Question

He encontrado un artículo de 2008 discutiendo acerca de cómo llamar a código Java desde MySQL . Había un montón de advertencias y renuncias porque el proceso consistía en trabajar con una rama experimental de MySQL.

Para un proyecto que tengo en mente, sería muy útil para poder acceder a bibliotecas de Java dentro de MySQL, análoga a Procedimientos almacenados Java . ¿Tiene esta capacidad ahora existe como una característica estándar de MySQL? Si no, ¿qué fuente abierta RDBMS apoyo algo similar a Java de Oracle procedimientos almacenados?

Answer 1

PostgreSQL soporta lenguajes de procedimiento enchufables, y existe un proyecto para extender PostgreSQL con PL / Java como el idioma.

No recomiendo poner demasiado código en el RDBMS. Herramientas para desarrollar, probar y depurar el código en la capa de aplicación son mejores que las herramientas de código en el RDBMS.

También muchos desarrolladores no entienden que el código dentro del RDBMS debe obedecer aislamiento de la transacción. Ellos tratan de enviar mensajes de correo electrónico de los desencadenantes y así sucesivamente. Creo código con efectos secundarios debe estar en la capa de aplicación, por lo que no se crea efectos fantasma (por ejemplo, un correo electrónico puede notificar un cambio de base de datos, a pesar de que el cambio se ha deshecho).

Answer 2

Si puede utilizar HSQLDB continuación, puede llamar a los métodos de Java directamente desde SQL: http://hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html#N1240C

Answer 3

Estoy totalmente de acuerdo con Bill, pero puedo imaginar reglas de negocio se almacenan (no procesados) en la base de datos. Estoy pensando en drools aquí. El motor estaría en la aplicación, pero las reglas podría estar en la base de datos con un front-end de gestión.

Tal bestia sería interesante para los escenarios en los que no sólo cambian los parámetros, sino también las fórmulas puede cambiar.

Answer 4

Es difícil dar un buen consejo sobre la base de la escasa información que ha proporcionado hasta ahora. Sin embargo:

  

... el ejemplo implica un tipo de datos basado en la gráfica (estructuras químicas) que no puede ser igualada a una consulta utilizando funciones de MySQL incorporado. La biblioteca de Java sería convertir la consulta y el contenido de un campo de texto en un objeto en memoria que puede por emparejados. Mantener esta lógica en la capa DB sería, por ejemplo, se une a mantener dentro de la base de datos, lo que parece al que pertenecen. Esa es la idea, por lo menos.

No creo que me gustaría utilizar la base de datos del lado de Java en MySQL para esto. En lugar de ello, creo que lo considere las siguientes opciones:

• Utilice un mapeo objeto-relacional tal como JDO o JPA (por ejemplo, usando Hibernate) para tratar con el mapeo entre el modelo de datos basado en el gráfico y lo que la base de datos proporciona. Usted no necesariamente tiene que utilizar un RDBMS como backend, pero que es probablemente el mejor lugar para empezar ... a menos que ya haya encontrado que este es un problema de rendimiento.

• Eche una mirada a su modelo de datos y patrones de acceso a datos. Ver si se puede averiguar algún tipo de transformación que permite a los principales consultas de su aplicación se ejecutará en el (eficiente) se une a la mesa sin tener que recurrir a la lógica de la aplicación del lado del servidor.

• Si es necesario utilizar la lógica de aplicación del lado del servidor (por razones de rendimiento!) Se pega con los mecanismos soportados por su RDBMS. Por ejemplo, en Oracle tendrá que utilizar PL / SQL y PostgreSQL tiene una serie de opciones. Esté preparado para cambiar a otro RDBMS que mejor se adapte a sus necesidades de aplicación.

I (personalmente) evitaría en función de una rama experimental de alguna base de datos:

• Considere lo que sucede si la rama experimental no está incluido de nuevo en la rama principal. Se podría ser pegado con su base de código en función de una rama que no es compatible, y es probable que deje de ser mantenido y esfumarse.

• El uso de un (actualmente) no soportada rama RDBMS será un impedimento para otras personas que quieran utilizar su software.

Ahora, obviamente, si la viabilidad a largo plazo de su software no es una preocupación primordial, podría elegir ignorar este consejo. Pero es probable que le importa a alguien; p.ej. el supervisor de investigación.