繁体 English 中英

完全用 PL/SQL 编写大型批处理程序是愚蠢的吗？

[英]Is it stupid to write a large batch processing program entirely in PL/SQL?

原文 2008-09-17 00:21:09 4 11 oracle/ plsql/ batch-processing

我正在开发一个程序，该程序可能最自然地描述为对数据库表进行批量计算，并且将每月执行一次。 所有输入都在 Oracle 数据库表中，所有输出都将在 Oracle 数据库表中。 该程序应该在未来许多年内保持可维护性。

将其实现为一系列存储过程似乎很简单，每个存储过程都执行合理的转换，例如根据某些业务规则在部门之间分配成本。 然后我可以编写单元测试来检查每个转换的输出是否符合我的预期。

在 PL/SQL 中完成这一切是一个坏主意吗？ 您是否愿意使用典型的面向对象编程语言（例如 C#）进行大量批量计算？ 使用以数据库为中心的编程语言（例如 PL/SQL）不是更具表现力吗？

11 个解决方案

您描述了以下要求

a) 必须能够实现批处理 b) 结果必须是可维护的

我的回复：

PL/SQL 旨在实现您所描述的内容。 同样重要的是要注意 PL/SQL 的效率是其他工具所不具备的。 存储过程语言将处理放在数据旁边——这是批处理应该放置的地方。
用任何语言编写可维护性差的代码都很容易。

综上所述，您的实施将取决于可用的技能、正确的设计和对高质量流程的遵守。

为了提高效率，您的实现必须批量处理数据（批量选择和批量插入/更新）。 OO 方法的危险在于它很容易被引向逐行处理数据的设计。 这种类型的方法包含不必要的开销，并且比分批处理数据的设计效率要低得多。

可以成功地使用这两种方法。

马修巴特勒

其他评论者需要注意的事情 - 问题是关于 PL/SQL，而不是关于 SQL。 一些答案显然是关于 SQL，而不是 PL/SQL。 PL/SQL 是一种功能齐全的数据库语言，而且它也很成熟。 有一些缺点，但是对于海报想要做的类型的事情来说，这是非常好的。

不，这不一定是个坏主意。 如果该解决方案对您来说看起来很简单，并且允许您测试和验证每个流程，那么这听起来可能是一个好主意。 OO 平台可能（尽管它们不一定）对大型数据集不利，因为对象创建和开销会降低性能。

Oracle 设计 PL/SQL 时就考虑到了您的问题，如果企业对数据库和 PL/SQL 有足够的了解，这似乎是一个合理的解决方案。 记住大批处理集，因为从 PL/SQL 到实际 SQL 引擎的每次调用都是上下文切换，因此应尽可能将单个记录进程批处理在一起以提高性能。

只要确保你以某种方式记录它工作时发生的事情。 否则你就会有一个黑匣子，如果它在某个地方卡住了几个小时，你会想知道是停止它还是让它“多一点”工作。

PL/SQL 是一种成熟的语言，可以很好地与 SQL 集成。 随着 Oracle 的每个版本，它变得越来越强大。 同样从 Oracle 11 开始，PL/SQL 默认编译为机器代码。

通常我会说在 PL/SQL 中尽可能少地投入——它通常不太易于维护——在我最近的一项工作中，我真的看到了使用它会变得多么混乱和困难。

但是，由于它是批处理 - 并且因为输入和输出都是 DB - 将逻辑放入 PL/SQL 是很有意义的 - 以最小化“移动部件”。 但是，如果它是业务逻辑 - 或系统其他部分使用的组件 - 我会说不要这样做..

我用 PL/SQL 和 Pro C 为一个项目编写了大量批处理和报告生成程序。 他们通常更喜欢我用 PL/SQL 编写，因为他们自己的开发人员将来会维护，发现这比 Pro C 代码更容易理解。

它最终只是最终用 Pro*C 编写的真正时髦的处理或报告。

没有必要像其他人提到的那样将这些编写为存储过程，它们可以只是根据需要运行的脚本文件，有点像 shell 脚本。 使测试和生产系统之间的源代码修订控制和迁移也变得更加容易。

只要您需要执行的计算可以在 PL/SQL 中充分且可读地捕获，那么仅使用 PL/SQL 将是最有意义的。

真正的问题是可维护性 —— 编写不可维护的 SQL 非常容易，这仅仅是因为一旦您脱离了简单的 SQL DML，并且没有真正的格式化标准，每个 RDBMS 都有不同的语法和不同的函数集。 评论等

我已经使用 C# 和 SQL 创建了批处理程序。

C#的优点：

您已经拥有完整的 .NET 库和面向对象语言的所有功能。

C# 的缺点：

批处理程序和数据库分开 - 这意味着，您必须将批处理程序与数据库分开管理。
您需要转义所有 dang sql 代码

SQL的优点：

与 DBMS 很好地集成。 如果此作业仅操作数据库，则将其包含在数据库中是有意义的。 您最终会在一个包中获得一个数据库及其所有组件。
无需转义sql代码
保持真实——你正在你的问题域中编程

SQL 的缺点：

它的 SQL 和我个人只是不了解它以及 C#。

一般来说，由于上面概述的优点，我会坚持使用 SQL。

这是一个沉重的问题:) 您应该了解一些数据库编程架构设计，以及它们的成本/收益是什么。 2 层通常意味着您有一个客户端连接到数据库，发出直接 SQL 调用。 3 层通常意味着您有一个“应用程序服务器”，它向数据库发出直接 SQL 调用，但客户端正在与应用程序服务器通信。 通常，这提供了“横向扩展”。 最后，您有 2 1/2 层应用程序，它们采用类似 2 层的格式，只有工作在存储过程中进行了划分。

您的流程听起来像是“后台”之类的事情，客户/流程只需要每月汇总和缓存一次的结果。 也就是说，没有代理连接，并且经常连接，并说“做这些计算”。 相反，您提到了一个偶尔发生的过程，您可以摆脱非实时。

因此，考虑到这些要求，我会说一般来说，更接近数据会更快，让 SQL Server 完成所有计算。 我想你会发现接近数据会很好地为你服务。

但是，在执行这些计算时，您可能会发现某些计算不适用于 SQL Server。 以计算债券或任何固定收益工具的应计利息为例。 在 SQL 中不是很漂亮，更适合更丰富的编程语言。 但是，如果您只有简单的平均值和其他相对合理的聚合，我会坚持使用 SQL 端的存储过程。

再说一次，没有足够的信息来说明您的计算性质，或者您的房子在开发人员的 SQL 支持能力方面的要求，或者您的老板所说的话……但因为我知道我的 SQL 方法，并且喜欢保持接近数据，对于这样的任务，我会保持纯 SQL/存储过程。

YMMV :)

它通常不会更具表现力，因为大多数存储过程语言在设计上都很糟糕。 但它可能会比在外部应用程序中运行得更快。

我想这归结为你对 PL/SQL 有多熟悉，你需要花多少时间来写这个，性能有多重要，以及你是否可以合理地期望维护者对 PL/SQL 足够熟悉来维护一个用 PL/SQL 编写的大程序它。

如果速度无关紧要并且维护人员可能不精通 PL/SQL，那么使用“传统”语言可能会更好。

您还可以使用混合方法，使用 PL/SQL 生成中间数据（例如，表连接和总和或其他）和一个单独的应用程序来控制流和检查值和错误。