什么时候应该将Java存储过程与Oracle数据库一起使用……有什么缺点？

PL / SQL不是我的母语。 Oracle支持使用Java编写存储过程。 与用PL / SQL编写存储过程相比，这样做有什么好处？

---

在Oracle世界中，一般的开发顺序应为：

只要有可能，就完全使用SQL来完成。
如果您需要的不仅仅是SQL，请使用PL / SQL。
如果您需要PL / SQL无法执行的操作，请使用Java。
如果所有其他方法均失败，请使用C。
如果您无法使用C做到这一点，请慢慢退后去解决问题....

PL / SQL存储过程是将业务逻辑转移到任何集成技术都可以访问的层的绝佳方法。包中的业务逻辑(不要编写独立的函数和过程-它们会以无法管理的方式随着时间的推移而增长)可以由Java，C＃，PL / SQL，ODBC等执行。

PL / SQL是在纯SQL之外处理大量数据的最快方法。"批量绑定"功能意味着它可以与SQL引擎一起很好地工作。

Java存储过程最适合创建与网络或操作系统交互的功能。例如，发送电子邮件，FTP'ing数据，输出到文本文件并将其压缩，通常执行主机命令行。

使用Oracle时，我从不需要编写任何C语言，但是大概可以将其用于与旧版应用程序集成。

---

仅当您无法在PL / SQL中做到这一点时(或PL / SQL证明速度太慢，我相信这种情况很少见)。

作为一个案例研究...我们有一个在生产环境中运行的Java存储过程(Oracle 9i)，它最初是用Java编写的，因为当时我们认为Java很酷，这是我早已改变主意的事情。无论如何。有一天，数据库重新启动后崩溃，Java SP无法正常工作。经过oracle支持的反复交流之后，他们真的不知道问题出在哪里，唯一的建议就是停机。某些事情是不可行的。 30分钟后，我用PL / SQL重写了Java SP。

现在，它运行速度更快，是oracle" native"，与其他对象共享相同的部署过程，并且更易于调试。

PL / SQL是一种非常强大的语言。如果您正在编写存储过程，请花一些时间来学习它，而不仅仅是在Java中做事，因为这就是您所知道的。

---

主要优点是可以访问PL / SQL中未提供的API和语言功能。例如，我将它们用于正则表达式处理，文件/目录操作和XML解析。

有许多缺点：

• 工具支持差

• 缺乏对JVM的控制

• DBA通常没有经过Java培训。为了支持您的生产代码，您要么需要对DBA进行更多的培训，要么雇用受过Java培训的支持人员

将Java移至应用程序服务器通常是一种更好的方法，因为这可以抵消这些缺点。出色的工具支持，对JVM的强大控制以及在流行的应用服务器中接受过大量培训的人员，因此轻松找到支持人员。从数据库移开性能命中有机会成本，但是使Java靠近数据库并不能给您带来很大的性能提升。

您绝对需要一个理由通过a)PL / SQL存储过程或b)数据库外部的Java在数据库中使用Java。

---

Java使编写与数据库无关的代码成为可能。它使您可以重用现有代码并大大提高生产率。

我发现Java存储过程有用的一件事是文件IO。与Oracle的UTL_FILE软件包相比，Java具有丰富得多的文件IO功能集，允许开发人员删除文件，添加目录等。

---

如果您绝对不能在PL / SQL中使用Java，或者Java可以提高性能，请使用Java。

例如，如果您希望在PL / SQL程序中使用套接字(日志记录，外部调用等)，则可以：

编写一个使用UTL_TCP的PL / SQL客户端。但是，无法仅使用本机PL / SQL进行UDP。

编写一个使用TCP或UDP套接字的Java客户端。

在第一种情况下，您有一个同步套接字，如果远程服务有问题，它可以备份您的PL / SQL调用。另外，如果您使用的是dbms_session.reset_package(与OWA中一样)，则必须为每个请求重新连接套接字，这是非常昂贵的。

在第二种情况下，TCP仍然是同步的，但是如果您需要异步的非阻塞行为，则可以使用UDP。此外，reset_package不会重置Java TCP或UDP套接字，因此您无需处理拆除/重新连接的麻烦。

---

优点：

• 可以在客户端和数据库中共享相同的应用程序逻辑
• 访问Java API。注意每个数据库支持哪个Java版本-我相信10g仅支持1.4(这意味着在我的工作中，我们必须非常小心，因为我们的主要代码库最近已移至1.5)。

缺点：

• Java存储过程执行大量数据库访问可能会非常慢
• 难以部署代码

---

我已将Oracle嵌入式Java用于两个问题：

1)执行一个PLSQL过程，该过程将查询结果批量存储在一个文本文件中，并通过FTP发送。这个文件很大，我用Java压缩它。

2)在与数据库直接连接的客户机/服务器应用程序中，比较用MD5散列的用户发送的密码与应用程序的密码(不是数据库的用户密码)，以使密码不会被网络以纯文本格式传输。我不确定这是否是解决此问题的更好解决方案，我现在要问它。 :)

---

答案永远不会。如果需要编写程序来加载或处理数据，则需要从网络上的另一台计算机在数据层之外进行。

当本机查询语言更适合手头工作时，直接在您的数据层上运行外部应用程序或禁止在数据层中进行进程内操作或外部语言的错误应用是很好的，并且对于小规模的内部定制业务是完全可以接受的应用。他们根本不在那个领域之外。

---