3

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

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

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

4

11 回答 11

10

您描述了以下要求

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

我的回复：

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

如上所述，您的实施将取决于可用的技能、适当的设计和对高质量流程的坚持。

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

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

马修·巴特勒

于 2008-09-18T12:12:35.483 回答
8

其他评论者需要注意的一点 - 问题是关于 PL/SQL，而不是关于 SQL。一些答案显然是关于 SQL，而不是 PL/SQL。PL/SQL 是一种功能齐全的数据库语言，而且它也很成熟。有一些不足之处，但对于发帖人想做的事情类型来说，还是很不错的。

于 2008-09-17T15:40:40.547 回答
6

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

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

于 2008-09-17T00:28:57.527 回答
4

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

于 2008-09-17T03:15:50.043 回答
4

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

于 2008-09-17T23:37:38.467 回答
3

通常我会说尽可能少地使用 PL/SQL——它通常更难维护——在我最后的工作之一中，我真的看到了使用它会变得多么混乱和困难。

然而，由于它是批处理——并且由于输入和输出都是数据库——将逻辑放入 PL/SQL 中是很有意义的——以最大限度地减少“移动部件”。但是，如果它是业务逻辑 - 或系统其他部分使用的组件 - 我会说不要这样做..

于 2008-09-17T00:24:25.260 回答
3

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

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

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

于 2008-09-17T01:25:20.510 回答
2

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

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

于 2008-09-17T00:25:53.507 回答
2

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

C#的优点：

  • 您拥有完整的 .NET 库和 OO 语言的所有功能。

C# 的缺点：

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

SQL的优点：

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

SQL的缺点：

  • 它的 SQL 和我个人对它的了解不如 C#。

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

于 2008-09-17T00:37:25.057 回答
1

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

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

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

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

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

YMMV :)

于 2008-09-17T00:35:54.013 回答
0

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

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

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

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

于 2008-09-17T00:27:14.860 回答