PL/SQL 是 SQL 的过程扩展，使得编写包含 SQL 的过程代码变得非常简单，就像它是一种单一语言一样。相比之下，大多数其他编程语言都需要映射数据类型、准备语句和处理结果集，所有这些都需要了解特定的 API。
PL/SQL 中的数据类型是数据库中的数据类型的超集，因此在使用 PL/SQL 时您很少需要执行数据类型转换。询问您的普通 Java 或 .NET 程序员他们如何发现处理来自数据库的日期值。他们只能希望 PL/SQL 的简单性。
在中间层应用程序中编写业务逻辑时，单个业务事务可能由应用程序服务器和数据库之间的多个交互组成。这增加了与网络流量相关的大量开销。相比之下，在数据库中将所有业务逻辑构建为 PL/SQL 意味着客户端代码每个事务只需要一次数据库调用，从而显着降低了网络开销。
Oracle 是一个多平台数据库，使 PL/SQL 和令人难以置信的可移植语言。如果您的业务逻辑位于数据库中，那么您就是在保护自己免受操作系统锁定。
编程语言不断地进进出出。在过去的 35 多年中，Oracle 数据库一直是企业环境的一部分。建议任何语言都比 PL/SQL 更安全是相当幼稚的。如果您喜欢追随时尚，将您的业务逻辑放在数据库中可以更简单地更改您的客户端层。
集中应用程序逻辑可实现更高程度的安全性和生产力。应用程序接口 (API) 的使用可以从客户端应用程序开发人员那里抽象出复杂的数据结构和安全实现，让他们可以自由地做他们最擅长的事情。
PL/SQL 架构
PL/SQL 语言实际上由两种不同的语言组成。过程代码由 PL/SQL 引擎执行，而 SQL 被发送到 SQL 语句执行器。
在大多数情况下，这两种语言之间的紧密结合使 PL/SQL 对大多数开发人员来说看起来像是一种单一的语言。
我的乌托邦式开发环境
很多年前我写了一篇关于这个的博客文章。你可以在这里阅读。我认为值得花一点时间在这里重申一些要点。它可能不是每个人都喜欢的，但我一直认为它是我遇到的最安全和最灵活的方法。
我相信 PL/SQL 应用程序接口 (API) 的使用应该是强制性的。理想情况下，客户端应用程序开发人员不应该访问表，而是通过 PL/SQL API 访问数据，或者在绝对必要时可能访问视图。下图显示了这种关系。
实际上，该组织可能会稍微复杂一些。也许像下面的例子。
这有许多有益的影响，包括：
- 安全和审计机制可以在数据库级别实施和维护，对客户端应用程序层几乎没有影响。
- 它消除了对触发器的需求，因为所有插入、更新和删除都包含在 API 中。无需编写触发器，您只需将代码添加到 API 中。
- 它可以防止不懂 SQL 的人编写低效的查询。所有 SQL 都应该由 PL/SQL 开发人员或 DBA 编写，从而减少错误查询的可能性。
- 数据库的底层结构对客户端应用程序开发人员是隐藏的，因此它隐藏了复杂性，并且可以在不更改客户端应用程序的情况下进行结构更改。
- 可以在不影响客户端应用层的情况下更改和调整 API 实现。减少重新部署应用程序的需要。
- 访问数据库的所有应用程序都可以使用相同的 API。从而减少重复劳动。
- 这些 API 可以使用 XML 或 JSON 呈现为 Web 服务。参见ORDS。
这听起来有点极端，但这种方法一次又一次地为我带来了红利。让我们详细阐述这些要点，以解释为什么这种方法如此成功。
一个可悲的事实是，审计和安全性通常只有在发生不好的事情后才被关注。能够修改和完善这些功能是一个巨大的好处。如果这意味着您必须重构整个应用程序，那么您将遇到问题。另一方面，如果它可以在您的 API 层中进行修改，那么您就是赢家。
在我看来，过度依赖数据库触发器是一件坏事。似乎我工作过的每一家公司都曾使用过触发器来修补“漏洞”或在其应用程序中实现某些业务功能。每次看到这个我的心都沉了下来。这些触发器总是会被意外禁用，并且一些功能会丢失，或者人们忘记它们的存在并在应用程序的其他地方重新编码它们的一些功能。将事务处理封装在包含所有必要功能的 API 中要容易得多，从而完全不需要表触发器。
许多客户端应用程序开发人员必须能够使用多个数据库引擎，因此并不总是非常精通针对 Oracle 数据库进行编码。除此之外，一些开发架构（如 J2EE）积极阻止开发人员直接使用数据库。你不会请一个没有经验的人来修你的车，那你为什么要让一个人为你写 SQL 呢？在 API 中抽象 SQL 使客户端应用程序开发人员可以做他们最擅长的事情，而您的 PL/SQL 程序员可以编写最有效的 SQL 和 PL/SQL。
在应用程序的生命周期中，数据库的物理实现可能会发生许多变化。认为设计会在应用程序开发开始之前完善是件好事，但实际上这种情况似乎很少。API 的使用将开发人员从数据库的物理实现中抽象出来，允许在不影响应用程序的情况下进行更改。
同样，不可能在应用程序的编码阶段预见所有可能的性能问题。很多时候，开发人员会使用不切实际的数据编写和测试代码，结果却发现在开发环境中运行良好的代码在生产环境中运行不佳。如果将数据操作层编码为 API，则无需重新编码应用程序的部分即可对其进行调整，毕竟实现已更改，而不是接口。
我一次又一次看到的一个问题是，公司在将业务逻辑编码到应用程序服务器的中间层方面投入了大量资金，然后希望直接将数据加载到数据库中，或者通过不会链接到他们的工具的工具来执行数据加载。中间层应用程序。结果，他们必须将业务逻辑的部分重新编码为 PL/SQL 或其他一些客户端语言。请记住，这不仅仅是编码过程中的重复工作，还有后续的维护。由于每种值得使用的语言都可以通过 OCI、JDBC、ODBC 或 Web 服务与 Oracle 对话，因此将您的逻辑保留在数据库中并让每个应用程序或数据加载使用相同的编程投资是有意义的。
当然，您可能并不总是能够完全控制您的开发环境，但请牢记这些要点。
下面列出了可能对开发 API 层有用的其他功能。
