PL/SQL 是 “Procedural Language extensions to the Structured Query Language.”的缩写。
Oracle 公司推出 PL/SQL 是为了克服 SQL 中的一些限制，并为那些寻求构建针对 Oracle 数据库运行的关键任务应用程序的人们提供更完整的编程解决方案。
PL/SQL的特点：
SQL是声明性、非过程性的编程语言。
1988 年，Oracle 公司发布了 Oracle 版本 6，这是其关系数据库技术的重大进步。 该版本的一个关键组件是所谓的过程选项，即 PL/SQL。 大约在同一时间，Oracle 发布了期待已久的 SQL Forms 2.3 版升级版（该产品的原始名称现在称为 Oracle Forms 或 Forms Developer）。 SQL*Forms v3 首次在工具方面整合了 PL/SQL 引擎，允许开发人员以自然、直接的方式编码其过程逻辑。
PL/SQL解决了 Oracle 数据库和工具在其早期的2个关键弱点：缺乏可移植性和执行权限问题。
Oracle数据库是用C语言编写的
PL/SQL 语言过去（现在）旨在扩大可以完全在独立于操作系统的编程工具中处理的应用程序需求的范围。 PL/SQL对于可移植性的要求比Java更早，它继续允许开发人员编写高度可移植的应用程序代码。
PL/SQL 语言提供对逻辑事务的严格控制和管理。 PL/SQL 实现此目的的一种方法是使用执行权限的实现。 您无需授予角色或用户更新表的权限，而是仅授予执行过程的权限，该过程控制并提供对底层数据结构的访问。这使得PL/SQL成为交易的“看门人”。这就是AUTHID子句，可以控制是使用调用者权限还是定义者权限。
尽管 SQL 功能强大，但它无法提供开发人员创建成熟应用程序所需的灵活性和功能。 Oracle 的 PL/SQL 语言确保我们可以完全处于独立于操作系统的 Oracle 环境中，并且仍然编写满足用户需求的高效应用程序。
随着PL/SQL不断发展，它添加了大量内置包，以多种方式和方向扩展了 PL/SQL 语言。 它引入了面向对象的功能，实现了各种类似数组的数据结构，增强了编译器以优化我们的代码并提供有关可能的质量和性能问题的警告，并且总体上提高了该语言的广度和深度。
PL/SQL易于学习，因为：
PL/SQL 最重要的方面之一是它与 SQL 的紧密集成。 您不需要依赖任何中间软件“粘合剂”，例如 ODBC或 JDBC。 您只需将 UPDATE 或 SELECT 插入代码中。
以下是一个匿名PL/SQL 块：
DECLARE
...
BEGIN
SELECT ...
...
UPDATE ...
END;
PL/SQL 使我们能够非常严格地控制程序的执行流。 包括：
Oracle可以创建可重用的PL/SQL块，即过程和函数，以下是一个过程的示例：
-- 创建存储过程
CREATE OR REPLACE PROCEDURE conditional_procedure (
p_input_parameter IN NUMBER
) AS
v_output_message VARCHAR2(100);
BEGIN
-- 使用条件判断执行不同的逻辑
IF p_input_parameter > 0 THEN
v_output_message := 'Input parameter is positive.';
ELSIF p_input_parameter = 0 THEN
v_output_message := 'Input parameter is zero.';
ELSE
v_output_message := 'Input parameter is negative.';
END IF;
-- 打印输出信息
DBMS_OUTPUT.PUT_LINE(v_output_message);
END conditional_procedure;
/
-- 调用存储过程
DECLARE
v_input_param NUMBER := 10;
BEGIN
conditional_procedure(v_input_param);
END;
/
PL/SQL 语言提供了强大的引发和处理错误的机制。
-- 创建自定义异常
CREATE OR REPLACE PROCEDURE custom_exception_procedure (
p_input_parameter IN NUMBER
) AS
-- 声明自定义异常
custom_exception EXCEPTION;
PRAGMA EXCEPTION_INIT(custom_exception, -20001);
BEGIN
-- 使用条件判断执行不同的逻辑
IF p_input_parameter > 0 THEN
DBMS_OUTPUT.PUT_LINE('Input parameter is positive.');
ELSIF p_input_parameter = 0 THEN
DBMS_OUTPUT.PUT_LINE('Input parameter is zero.');
ELSE
-- 抛出自定义异常
RAISE custom_exception;
END IF;
EXCEPTION
-- 捕获自定义异常
WHEN custom_exception THEN
DBMS_OUTPUT.PUT_LINE('Input parameter is negative. Custom Exception Raised.');
-- 捕获其他异常
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('An error occurred: ' || SQLERRM);
END custom_exception_procedure;
/
-- 调用存储过程
DECLARE
v_input_param NUMBER := -5;
BEGIN
custom_exception_procedure(v_input_param);
END;
/
Oracle 数据库的每个版本都带有其自己对应的 PL/SQL 版本，也就是说数据库的版本就是PL/SQL的版本。 版本越新，功能越多。PL/SQL 程序员最大的挑战之一就是跟上。 我们需要不断地自我教育每个版本中的新功能，弄清楚如何使用它们以及如何将它们应用到我们的应用程序中，并确定哪些新技术非常有用，以至于我们应该修改现有应用程序以利用它们。
SQL> select banner FROM v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
O’Reilly 于 1995 年出版了本书的第一版。
我们几乎总是在紧迫的期限内工作，或者在一次又一次的挫折中奋起直追。 我们没有时间可以浪费，还有大量的代码要编写。 那么让我们开始吧——对吧？
错误的。 如果我们太快地深入代码构建的深处，盲目地将需求转换为数百、数千甚至数万行代码，我们最终会陷入一团糟，几乎无法调试和维护。 不要惊慌地应对迫在眉睫的最后期限； 如果您仔细计划，您更有可能在最后期限前完成任务。
我强烈建议您抵制这些时间压力，并确保在启动新应用程序，甚至在应用程序中的特定程序之前进行以下操作：
在编写代码之前构建测试用例和测试脚本
在编写一行程序之前，您应该确定如何验证是否成功实现。 如果这样做，您更有可能获得正确的程序接口，因为它将帮助您彻底确定程序需要做什么。
为开发人员如何在应用程序中编写 SQL 语句制定明确的规则
一般来说，我建议个人开发人员不要编写大量 SQL。 相反，这些单行查询、插入和更新应该“隐藏”在预先构建且经过彻底测试的过程和函数后面（这称为数据封装）。 与分散在代码中的 SQL 语句（其中许多是冗余的）相比，这些程序可以更有效地优化、测试和维护。
为开发人员如何处理应用程序中的异常建立明确的规则
团队中的所有开发人员都应该以相同的方式提出、处理和记录错误。 执行此操作的最佳方法是创建一个错误处理包，该包隐藏如何保留错误日志的所有详细信息，确定如何引发异常并通过嵌套块向上传播，并避免对特定于应用程序的异常进行硬编码。 确保所有开发人员都使用此包，并且他们不会编写自己的复杂、耗时且容易出错的错误处理代码。
使用自上而下的设计（也称为逐步细化）来限制您在任何给定时间必须处理的需求的复杂性
如果您使用这种方法，您会发现模块的可执行部分更短且更容易理解，这使得您的代码随着时间的推移更容易维护和增强。 使用本地或嵌套的模块对于遵循这一设计原则起着关键作用。
这些只是在开始编写所有代码之前需要记住的一些重要事项。 请记住：在软件开发的世界中，仓促不仅会造成浪费，而且实际上会导致大量的错误和损失的周末。
软件专业人士通常很聪明。 不幸的是，您的成功也可以使您保持自负，自大和不愿意在您感到困惑时寻求帮助。 这种趋势是软件开发中最危险和最具破坏性的方面之一。
软件由人类撰写； 因此，重要的是要认识到人类心理学在软件开发中起着关键作用。
诸如“我为什么不看到的？”以及“如果我多花五分钟时间自己调试，我会发现它” 的想法是可以理解的，但也很愚钝（thick-headed）。 最重要的是，我们通常无法识别自己的问题，因为我们离我们自己的代码太近了。 有时，我们所需要的只是一个新的视角，这是一个无所事事的人的相对客观观点。 它与资历，专业知识或能力无关。
我们强烈建议您在组织中制定以下准则：
奖励承认无知
隐藏您不了解的应用程序或其代码是非常危险的。 培养一种欢迎提问和请求帮助的文化。
请求帮忙
如果您无法在 30 分钟内找出错误来源，请立即寻求帮助。 你甚至可以建立一个“伙伴系统”，这样每个人都会被分配一个需要寻求帮助的人。 不要让自己（或团队中的其他人）花费数小时以头撞墙，徒劳地寻找答案。
建立正式的同行代码审查流程
不要让任何代码在没有被团队中的一名或多名其他开发人员阅读和批评（以积极、建设性的方式）的情况下进入质量检查或生产阶段。
我们几乎在生活的各个方面都容易陷入墨守成规的境地。 人是习惯的生物：你学会用一种方式编写代码；您假设产品存在某些限制； 你没有认真检查就放弃了可能的解决方案，因为你觉得这是不可能的。 开发人员对自己的程序产生了彻头彻尾的偏见，而且通常不是以积极的方式。 人们经常听到他们说这样的话：
但现实是你的程序几乎总是可以运行得更快一点。 你需要打破你顽固观点的限制，以全新的眼光看待世界。 重新评估您养成的编程习惯。 发挥创造力——远离传统方法，远离我们业务场所不断强化的往往有限的机械方法。
尝试一些新的东西：尝试一些看似完全背离常态的东西。 作为一名程序员和问题解决者，你会惊讶地发现自己能学到很多东西，成长得也很多。 多年来，当我不再说“你做不到”时，我一次又一次地惊讶于自己真正可以实现的目标。