SQL存储过程的质量管理

Question

我一直在开发自己的应用程序，并使用特定的标准从质量的角度来评估代码是否可以接受。现在，我已经换了工作，并且不得不维护现有的软件。

在这里，他们将大部分业务逻辑放在存储过程中。这本身我认为是一个不好的做法，但它是我处理的手不管。现在，我看到他们使用包含超过2k的LoC (不包括注释)的存储过程，如果我将它应用到Java/C#/C中的方法中，我会给它一个很大的减号。

但是，我是否应该将存储过程视为使用质量度量的一种方法？例如，您可能会认为存储过程使用更多的LoC来实现某些事情，您应该考虑到这一点。但是，如果同样的方法由Java/C#中的20行代码组成，在存储过程中由50行组成，我觉得我应该考虑它，因为它降低了过程的可读性。

我是否应该使用https://www.researchgate.net/publication/4276839_一个_实用_模型_为_测量_维修性中描述的度量从可维护性的角度来查看代码是否可以接受？它们是: LoC、圈复杂度、单元大小、复制、可测试性(其中单元大小指的是一个方法，LoC指的是类的代码行总数)。

或者我应该使用不同的质量度量来从质量的角度看存储过程是否可以接受？在任何情况下都可以取消可测试性，因为据我所知，这里没有测试。

Answer 1

我要说，SQL环境与C传统中的标准编程语言的环境之间几乎没有可比性。

2k行的存储过程当然是一个相当大的大小，但是它所做的数据处理工作量的适当比较可能不是单个类，而是一个小应用程序。

SQL是一种非常古老的语言，在某种程度上它缺乏我们现在认为标准语言中理所当然的现代代码组织工具。

但是，对于数据库环境中出现的问题，它进行了相对调整。例如，在一个过程中拥有所有东西所带来的好处之一就是能够原子地更新过程，甚至不会使数据库离线。与此形成对比的是，在无数客户端计算机上更新桌面应用程序，这可能曾经是主要的选择。

它也是一种相对简单的方法来完成小型应用程序的工作，而不必离开数据库环境。所有这些都是用数据库备份的，并且事务上一致。

按照标准编程语言典型的粒度将其分解为多个子例程，通常会在SQL组织这些子程序并控制对它们的访问的限制范围内造成相当大的混乱。

因此，不，我不会试图从为标准编程语言量身定做的度量中得出任何类比。

当然，我不能说明使用存储过程是否适合在这种情况下所做的工作。更复杂的处理总是传递给用与SQL不同的语言编写的独立应用程序。

并且存储过程应该尽可能的结构良好，通过转换数据的步骤进行清晰的注释和顺序推进。但是，与标准语言中的代码相比，这里的良好结构将由不同的标准和妥协来判断，以及适用于它的任何研究。