如何从MySQL调用Java代码？

发布于 2024-08-17 04:26:41 字数 381 浏览 9 评论 0原文

我发现 2008 年的一篇文章讨论了如何从 MySQL 调用 Java 代码。由于该过程涉及使用 MySQL 的一个实验分支，所以有很多警告和免责声明。

对于我想要的一个项目，能够访问 MySQL 中的 Java 库将非常有用，类似于 Oracle 的 Java 存储过程。此功能现在是否作为 MySQL 的标准功能存在？如果没有，哪些开源 RDBMS 支持类似于 Oracle 的 Java 存储过程的功能？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

ヤ经典坏疍 2024-08-24 04:26:41

PostgreSQL 支持可插入过程语言，并且存在一个项目来使用 PL/Java 作为语言来扩展 PostgreSQL。

我不建议在 RDBMS 中放置太多代码。在应用程序层中开发、测试和调试代码的工具比在 RDBMS 中开发、测试和调试代码的工具更好。

此外，许多开发人员不明白 RDBMS 内部的代码应该遵守事务隔离。他们尝试通过触发器等发送电子邮件。我认为具有副作用的代码应该位于应用程序层，这样就不会产生幻影效果（例如，电子邮件可能会通知数据库更改，即使更改已回滚）。

回复收藏 0 原文

梦在深巷 2024-08-24 04:26:41

如果您可以使用 HSQLDB，那么您可以直接从 SQL 调用 java 方法： http ://hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html#N1240C

回复收藏 0 原文

回忆追雨的时光 2024-08-24 04:26:41

我完全同意 Bill 的观点，但我可以想象业务规则存储（而不是处理）在数据库中。我在这里想到drools。引擎将位于应用程序中，但规则可能位于具有管理前端的数据库中。

对于不仅参数会变化而且公式也会变化的场景，这样的野兽会很有趣。

回复收藏 0 原文

活雷疯 2024-08-24 04:26:41

根据您目前提供的有限信息，很难给出好的建议。然而：

...该示例涉及基于图形的数据类型（化学结构），无法与使用内置 MySQL 函数的查询匹配。 Java 库会将查询和文本字段的内容转换为可以匹配的内存中对象。例如，将此逻辑保留在数据库层中会将连接保留在数据库中，这似乎是它们所属的位置。至少是这个想法。

我认为我不会为此在 MySQL 中使用数据库端 Java。相反，我认为我会考虑以下选项：

使用对象关系映射，例如 JDO 或 JPA（例如使用 Hibernate）来处理基于图形的数据模型与数据库提供的内容之间的映射。您不一定必须使用 RDBMS 作为后端，但这可能是最好的起点...除非您已经发现这是一个性能问题。
再看看您的数据模型和数据访问模式。看看您是否可以找出某种转换，允许将应用程序的主要查询实现为（高效）表连接，而无需求助于服务器端应用程序逻辑。
如果您确实需要使用服务器端应用程序逻辑（出于性能原因！），请坚持使用 RDBMS 支持的机制。例如，在 Oracle 中您可以使用 PL/SQL，而 PostgreSQL 则有多种选择。准备好切换到更适合您的应用程序需求的不同 RDBMS。

我（个人）会避免依赖于某些数据库的实验分支：

考虑一下如果实验分支没有合并回主分支会发生什么。您的代码库将陷入困境，具体取决于不支持的分支，并且可能会停止维护并失败。
使用（当前）不受支持的 RDBMS 分支将会妨碍其他可能想要使用您的软件的人。
使用（

显然，如果您的软件的长期生存能力不是主要考虑的问题，您可以选择忽略此建议。但这可能对某些人来说很重要；例如你的研究主管。

It is difficult to give good advice based on the limited information that you have provided so far. However:

... the example involves a graph-based data type (chemical structures) that can't be matched to a query using built-in MySQL functions. The Java library would convert the query and contents of a text field into an in-memory object that can by matched. Keeping this logic in the DB layer would, for example, keep joins within the database, which seems like where they belong. That's the idea, at least.

I don't think I would use database-side Java in MySQL for this. Instead, I think I would consider the following options:

Use an object-relational mapping such as JDO or JPA (for example using Hibernate) to deal with the mapping between your graph-based data model and what the database provides. You don't necessarily have to use an RDBMS as the backend, but that is probably the best place to start ... unless you've already found that this is a performance issue.
Take another look at your data model and data access patterns. See if you can figure out some transformation that allows your application's main queries to be implemented as (efficient) table joins without resorting to server-side application logic.
If you do need to use server-side application logic (for performance reasons!) stick with the mechanisms supported by your RDBMS. For example, in Oracle you'd use PL/SQL and PostgreSQL you have a number of options. Be prepared to switch to a different RDBMS that better suits your application requirements.

I (personally) would avoid depending on an experimental branch of some database:

Consider what happens if the experimental branch is not merged back into the main branch. You would be stuck with your code base depending on a branch that is not supported, and is likely to stop being maintained and fizzle out.
Using a (currently) unsupported RDBMS branch will be an impediment to other folks who might want to use your software.

Now obviously, if the long term viability of your software is not a primary concern, you could choose to ignore this advice. But it probably matters to someone; e.g. your research supervisor.

回复收藏 0 原文