我正在开始一个程序的工作，该程序可能最自然地描述为对数据库表的一批计算，并且每月执行一次。 所有输入都在Oracle数据库表中，所有输出都将在Oracle数据库表中。 该程序应在未来很多年保持可维护性。
将其实现为一系列存储过程似乎很简单，每个存储过程都进行了明智的转换，例如，根据一些业务规则在部门之间分配成本。 然后，我可以编写单元测试以检查每个转换的输出是否符合我的预期。
在PL / SQL中全部完成这是一个坏主意吗？ 您是否愿意使用典型的面向对象编程语言（例如C＃）进行大量的计算？ 使用以数据库为中心的编程语言（例如PL / SQL）是否更具表达能力？
您描述以下要求
a）必须能够执行批处理b）结果必须可维护
我的回复：
综上所述，您的实施将取决于可用的技能，适当的设计以及对高质量流程的坚持。
为了提高效率，您的实现必须分批处理数据（分批选择，然后分批插入/更新）。 面向对象方法的危险在于，很容易将其引向逐行处理数据的设计。 这种类型的方法包含不必要的开销，并且其效率将大大低于按行处理数据的设计。
可以成功使用两种方法。
马修·巴特勒
其他评论者需要注意的问题-问题是关于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库和OO语言的所有功能。
C＃的缺点：
*批处理程序和数据库是分开的-这意味着，您必须与数据库分开管理批处理程序。
*您需要转义所有dang sql代码。
SQL的优点：
*与DBMS很好地集成。 如果此作业仅操作数据库，则将其包含在数据库中是有意义的。 您最终将一个数据库及其所有组件打包在一个程序包中。
*无需转义SQL代码
*保持真实-您正在问题域中进行编程
SQL的缺点：
它的SQL和我个人都不熟悉SQL。
通常，由于上述优点，我会坚持使用SQL。
这是一个充满挑战的问题：)您应该了解几个数据库编程体系结构设计，以及它们的成本/收益是什么。 2层通常意味着您有一个客户端连接到数据库，并发出直接的SQL调用。 3层通常表示您有一个“应用程序服务器”，它向数据库发出直接的SQL调用，但是客户端正在与应用程序服务器通信。 通常，这提供了“向外扩展”。 最后，您拥有采用2层格式的2 1/2层应用程序，只有工作在存储过程中进行了划分。
您的流程听起来像是“后台”，客户/流程只需要每月一次汇总和缓存结果。 也就是说，没有代理可以连接并且经常连接，并说“进行这些计算”。 相反，您暗示了一个不时发生的过程，并且您可以摆脱非实时性。
因此，考虑到这些要求，我通常会说，更接近数据会更快，让SQL Server执行所有计算。 我认为您会发现与数据的接近将为您提供很好的服务。
但是，在执行这些计算时，您可能会发现某些计算不适合SQL Server。 以计算债券或任何固定收益工具的应计利息为例。 SQL不是很漂亮，更适合于更丰富的编程语言。 但是，如果您只有简单的平均值和其他相对合理的聚合，那么我会在SQL方面坚持使用存储过程。
再说一次，关于您的计算的性质，您的房屋在开发人员的SQL功能方面的支持要求，您的老板说的是什么……都没有足够的信息……但是由于我了解我的SQL知识，并且喜欢保持接近数据，我将保持纯SQL / Stored Procedures这样的任务。
YMMV :)
由于大多数存储过程语言都是设计引起的，因此通常不更具表现力。 但是它可能比在外部应用程序中运行得更快。
我想这可以归结为您对PL / SQL的熟悉程度，必须编写多少时间，性能有多重要以及是否可以合理地期望维护人员对PL / SQL足够熟悉以维护编写的大型程序。它。
如果速度无关紧要，并且维护人员可能不熟练PL / SQL，则使用“传统”语言可能会更好。
您还可以使用混合方法，其中使用PL / SQL生成中间数据（例如，表联接和总和或其他），并使用单独的应用程序控制流以及检查值和错误。
