通过存储过程重用SQL Server代码 – 好或坏的做法？

我目前正在考虑基于现有数据集的报告应用程序的设计选项.

鉴于许多报告需要使用相同的基础数据集(已编辑),因此有许多明确的代码重用机会.

最简单的方法是创建一些我可以在整个系统中重用的基本存储过程,但是,我在6个月前左右的合同向我展示了这种做法的缺点 – 多层 – 大型存储过程调用返回的子集数据,使得进行正在进行的调试和测试非常困难.

我现在认为代码重用不一定会增强数据库设计的可维护性.

我正在寻找一个比我自己更有经验的sql Server开发人员的一些见解？

提前致谢.

解决方法

免责声明：这不是“不要使用存储过程 – 想想孩子们！”发布,我并不打算点燃火焰战争.我只是建议代码重用更容易,并且可能更适合某些情况和平台而不是其他情况.

代码重用作为一个概念通常可以改善代码库.你保留了DRY并开始形成一层通用功能,以同样的方式解决常见问题.

然而,就像任何事情一样,人们可能会弄错(权力来自责任等等等等).

在大多数现代编程语言中,通过编写函数或甚至创建可以反复使用的整个框架来重用代码相对简单.但是,在T-sql中它很棘手,因为你有更少的选项.存储过程可以做到,但你已经看到它们有多尴尬.

我个人的偏好是将业务逻辑保留在数据库之外.这意味着我不使用视图,UDF,sprocs等(除非在性能分析之后我们认为我们可以使用这些技术加速某些事情),而是将它保存在我的应用程序代码中.这通常会导致“业务逻辑层”的想法,但有各种各样的风格,所以它可能是用词不当.但它肯定不是直接在UI按钮点击处理程序后面的代码,等等.

我的目标是限制数据库存储和检索数据,因为这是他们真正擅长的.我们都知道笨拙和过时的T-sql可以作为一种语言(想想异常处理,部署,游标等).如果您的应用程序被写入数据库本身,并且您也无法扩展应用程序,那么与数据库无关是完全不可能的,因为数据库是应用程序.如果您在应用程序代码中具有该业务逻辑,则可以更轻松地扩展它.

在这种情况下,“业务逻辑”是用于生成报告的查询和转换,我将研究在考虑其他选项之前如何在报告工具/代码中重用代码.

原文地址：https://www.jb51.cc/mssql/77198.html