在 PL/SQL 中实现应用程序

Question

我们正在开发一个 Web 应用程序，根据我的规范，它的后端必须完全用 PL/SQL（存储过程等）编写。有人对如何使用存储过程和自定义类型编写结构良好的后端有任何建议/链接吗？通常我会有一个业务层，所有这一切都会发生，但雇主希望雇主得到什么等等。

Answer 1

您可以仍然拥有业务层 - 只是您使用 PL/SQL 而不是其他语言编写它。

典型的 PL/SQL 业务层会为每个主要功能领域使用包，其中包含适当的过程和功能，例如

create package employees_pkg as
    procedure hire_employee (p_id integer, p_name varchar2,
                             p_start_date date, ...);
    procedure terminate_employee (p_id integer, p_end_date date);
    ...
end;

这些包可以直接对表执行 DML，尽管有些人（不是我）会提倡在此之下使用“表 API”层，以便 employees_pkg.terminate_employee 将调用“employee_tapi.update(...)”而不是“UPDATE员工......”，这对我来说似乎毫无意义。

自定义类型有其用途，但我不会过分尝试在 PL/SQL 中构建 OO 层。

您没有说明您的客户端应用程序是用什么构建的，但 Oracle Application Express 将是基于 Web 的 Oracle 数据库应用程序的绝佳选择。

Answer 2

我读过规范说你不要在你的程序代码中构造或嵌入 SQL 语句，我希望你同意无论如何这是一个好的计划。

PL/SQL 与 Python 或 PHP 不同。因此，无论您通常在“业务层”中做什么，您仍然会以相同的方式进行操作。差异会出现在 DAL 中（您确实有一个，不是吗？）。您将使用 PL/SQL 作为带参数的函数调用，而不是 SQL。如果您愿意，它会成为您的 ORM，但在数据库中构建（并且可能比面向对象更面向功能）。

Answer 3

我不知道您的具体职责范围是什么，但您有义务向您的客户提供建议。我想我们都知道，如果应用程序的规模很大、容易增长或项目指定不明确（即敏捷环境），他所要求的就是灾难。

不管怎样，客户端不希望您直接从数据库中生成 HTML，是吗？

话虽如此，我开发了一个巨大的应用程序，该应用程序将很多（我想说的太多）推迟到数据库（不是 PL/SQL，而是 Oracle 和 MSSQL——这意味着两组存储过程——有时特定的表、视图、触发器和约束——维护）。从一般的角度来说我想说的是：

• 阅读，阅读，阅读
• 首先对架构进行详细分析（不要犹豫，将事物分解为许多不同的表，并使用视图将它们连接起来并获得更简单的数据库界面），
• 如果 PL/SQL 自定义类型很好，则将顶级表/视图隐藏在自定义类型后面（始终），
• 考虑模块化和“服务”来组织您的过程，
• 不要从一开始就尝试变得聪明/快速。

我的意思是这样的结构：

• 业务：存储过程和自定义类型
• 应用：视图、表、内部过程、内部类型
• 存储：基本架构（基表）、触发器和约束（小心操作）

哦，是的，尽早重构。应用程序越大，移动东西就越困难，尤其是在这样的环境中。

当然我不需要告诉你早点测试；）