Como chamar o código Java a partir do MySQL?

Question

Eu encontrei um artigo a partir de 2008 discutindo como chamada em código Java a partir do MySQL . Havia um monte de ressalvas e renúncias porque o processo envolveu o trabalho com um ramo experimental do MySQL.

Para um projeto que tenho em mente, seria muito útil para ser capaz de acessar as bibliotecas Java dentro do MySQL, análogo ao da Oracle procedimentos armazenados Java . Será que esta capacidade agora existe como um recurso padrão do MySQL? Se não, o open source apoio RDBMSs algo semelhante ao Java da Oracle procedimentos armazenados?

Answer 1

PostgreSQL suporta linguagens de procedimento conectáveis, e um projeto existe para estender o PostgreSQL com PL / Java como o idioma.

Eu não recomendo colocar muito código nos RDBMS. Ferramentas para desenvolver, testar e depurar o código na camada de aplicação são melhores do que ferramentas de código no RDBMS.

Além disso, muitos desenvolvedores não entendem que o código dentro do RDBMS deve obedecer isolamento da transação. Eles tentam enviar e-mails a partir de gatilhos e assim por diante. Acho código com efeitos colaterais devem estar na camada de aplicação, para que você não criar efeitos fantasmas (por exemplo, um e-mail pode notificar de uma mudança de banco de dados, mesmo que a alteração foi revertida).

Answer 2

Se você pode usar HSQLDB então você pode chamar métodos Java diretamente do SQL: http://hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html#N1240C

Answer 3

Concordo plenamente com Bill, mas posso imaginar regras de negócio que está sendo armazenado (não processado) no banco de dados. Estou pensando em drools aqui. O motor seria na aplicação, mas as regras pode ser no banco de dados com um front-end de gestão.

Tal besta seria interessante para cenários onde não só os parâmetros mudam, mas também as fórmulas podem mudar.

Answer 4

É difícil dar bons conselhos com base na informação limitada que você forneceu até agora. No entanto:

... o exemplo envolve um tipo de dados baseada em gráfico (estruturas químicas) que não pode ser igualada a uma consulta usando built-in funções MySQL. A biblioteca Java iria converter a consulta e conteúdo de um campo de texto em um objeto na memória que pode por correspondido. Mantendo esta lógica na camada DB seria, por exemplo, manter a junta no banco de dados, o que parece ser a que pertencem. Essa é a idéia, pelo menos.

Eu não acho que eu usaria-side banco de dados Java no MySQL para isso. Em vez disso, eu acho que eu iria considerar as seguintes opções:

• Use um mapeamento objeto-relacional como JDO ou JPA (por exemplo, usando Hibernate) para lidar com o mapeamento entre o modelo de dados baseado em gráfico e que o banco de dados fornece. Você não necessariamente tem que usar um RDBMS como o back-end, mas que é provavelmente o melhor lugar para começar ... a menos que você já encontrou que este é um problema de desempenho.

• Tome um outro olhar para o seu modelo de dados e acesso a dados padrões. Veja se você pode descobrir alguma transformação que permite principais perguntas do seu aplicativo para ser implementado como (eficiente) junções de tabela, sem recorrer a lógica da aplicação do lado do servidor.

• Se você precisa usar a lógica de aplicação do lado do servidor (por motivos de desempenho!) Vara com os mecanismos suportadas pelos RDBMS. Por exemplo, no Oracle você pode usar PL / SQL e PostgreSQL você tem um número de opções. Esteja preparado para mudar para um RDBMS diferente que melhor se adapte às suas necessidades de aplicação.

I (pessoalmente) evitaria dependendo um ramo experimental de algum banco de dados:

• Considere o que acontece se o ramo experimental não é mesclado volta para o ramo principal. Você iria ser preso com sua base de código, dependendo de um ramo que não é suportado, e é provável que pare de ser mantido e fracassar.

• Usando um (atualmente) não suportado ramo RDBMS será um impedimento para outras pessoas que possam querer utilizar o seu software.

Agora, obviamente, se a viabilidade a longo prazo de seu software não é uma preocupação principal, você pode optar por ignorar este conselho. Mas provavelmente é importante para alguém; por exemplo. o supervisor de pesquisa.