选择将 Oracle PL/SQL 迁移到 Java 类/EJB [关闭]答案

【问题标题】：Making a Choice on Migrating Oracle PL/SQL to Java Classes / EJB [closed]选择将 Oracle PL/SQL 迁移到 Java 类/EJB [关闭]
【发布时间】：2012-01-12 16:23:50
【问题描述】：

想知道在决定在 Java 类/EJB 中转换 PLSQL 的选项时可能是什么决策点/因素。

在前端是 PowerBuilder 的 PLSQL 中实现了相当多的业务逻辑。

现在为了使应用程序支持 Web，应用程序正在使用 Struts 框架迁移到 Java/J2EE。

有必要将 PLSQL 连同用户界面一起迁移，特别是当 RDBMS 继续在 Oracle 上并且有 PL/SQL 方面的专业知识可用时。

选择时要考虑哪些因素？

【问题讨论】：

有两种观点实际上是意识形态的：中间层的业务规则或数据库中的业务规则。没有明确的正确或错误答案，这真的取决于具体情况。但由于这是一个只能引发辩论的话题（而且是一个旧的辩论），我投票结束这个问题，因为它没有建设性。

标签： java oracle plsql ejb

【解决方案1】：

"是否需要与用户一起迁移 PLSQL 接口，特别是当 RDBMS 继续在 Oracle 和有 PLSQL 方面的专业知识。”

不仅没有必要，而且完全不可取。

你有一个 PL/SQL API （大概）可以工作。你有理解它并有能力维护它的人。您为什么要将其转移到 Java 中以没有明显的商业利益。

只要用 Java 编写前端，您就会获得足够的乐趣。在您对应用程序的其他层做出任何决定之前，先让其发挥作用。

最后一个想法：您有 PL/SQL 开发人员：为什么不在 Apex 中开发 Web 前端呢？

【讨论】：

+1 非常好，非常真实！我见过很多 Java 开发人员完全不关心数据库，更不用说转换一组工作的 pl/sql 包了
@APC 我觉得你的回答很有趣，因为它适合你的简历和工作安全。不能指望数据库开发人员有不同的观点。我完全理解你的担心。但是这个评论是在 2020 年。我知道在你回答 8 年后。你的答案不再是现代的了。现在，非常需要 ORM 和框架。与其只依赖像 oracle 这样的特定数据库，最好将存储过程中的业务逻辑移动到 java..so 之类的东西，明天我可以轻松地从 oracle 切换到任何其他数据库，因为 postgresql 是开源的..保存许可费用。
@Stunner - 组织多久将他们的应用程序从一种数据库产品转移到另一种？几乎从不。为什么？因为 RDBMS 是大量的状态。是的，这使得数据库“不那么敏捷”，不管这意味着什么，但它也使数据转移变得困难、昂贵和冒险。但是，有状态的好处是我们的数据是未损坏的、高度可用的，并且可以使用标准的行业工具轻松访问。我不是在这里为甲骨文的许可费辩护，它们是站不住脚的。但是，如果我们收购了 Oracle，那么获得最佳 ROI 的方法就是使用我们为之付出的一切。
@stunner - 顺便说一句，我第一次有这个论点是在 2001/2 年，一位 Java 架构师想要将我们所有的业务逻辑转移到 EJB 中。这将是 EJB 1.2 或其他东西，而不是几年后的轻量级 EJB 3 协议（以及对更轻量级实现的需求的赠品）。该数据库仍然是组织业务流程的一部分。你上一次写 EJB 是什么时候？
EJB 已死。同意。从一个框架迁移到另一个框架需要时间和精力，但与数据库的许可成本相比，这应该是值得的。我知道很多银行正在从 Oracle 迁移到像 MariaDB 和 PostgreSQL 这样的开源数据库，用于核心支付。开源将成为新常态，组织也将相应转变。

【解决方案2】：

如果您可以将 PL/SQL 隔离在适当的域模型后面，这可能不是问题，但如果您在PL/SQL。

我工作的情况是我们有很多业务逻辑，在 PL/SQL 中实现得很糟糕 - 我们有一个特殊的术语 - “Magical SQL”。因为我们没有像我们希望的那样多的 Oracle 资源，所以对遗留业务逻辑的任何更改都需要很长时间。我们正在尝试将逻辑迁移到 Java 层，纯粹是为了让我们的系统更易于维护和更敏捷。

简短的回答，这不是必需的，但它可能是明智的（在我看来） - 进行了修改以说明这显然取决于具体情况。

【讨论】：

你可以用“执行不力”来证明任何事情。我遇到过多少中间层，因为开发人员不了解基于集合的操作的重要性，令人震惊地实现的 ORM 在 RBAR 基础上检索大量数据？或者如何过滤数据库中的查询？等等等等。
@APC 我是 RDBMS 的坚定信徒，但在我们的特殊情况下，它已被严重滥用，因此我们正面临维护的噩梦。我以前工作过的系统包含编写得非常好、一致且隔离的 DB 层，我们可以很高兴地与之交互；那很棒。然而，有时，将其提取到中间层是两个象鼻虫中较小的一个。我想我想说的是它确实依赖于实例。
您的情况显然与 OP 完全不同。因此，根据您的经验向他们提供建议是错误的。这就是为什么我投票以非建设性来结束这个问题
尽管您说 PL\SQL 实现非常糟糕，因为您没有很多 Oracle 人员，您怎么知道您没有在 Java 中创建同样糟糕的接口？我们刚刚遇到了一些旧网站的代码，基本上是select random_number between 0 and 9。为什么？它是很久以前由对 Oracle 和/或数据一无所知的人写的。无论您在哪里开发您的逻辑，您都需要了解数据和知道如何使用数据库的接口的人。
唯一比非建设性问题更具建设性的是一个封闭的非建设性问题。