我目前正在考虑基于现有数据集的报告应用程序的设计选项。
鉴于许多报告需要使用相同的基础数据集（已编辑），代码重用有几个明显的机会。
模仿是创建一些我可以在整个系统中重用的基本存储过程，但是，我在6个月前左右的合同向我展示了这种做法的缺点 - 多层 - 大型存储过程调用返回数据子集，使得进行正在进行的调试和测试非常困难。
我现在认为代码重用不一定会增强数据库设计的可维护性。
我正在寻找一个比我自己更有经验的SQL Server开发人员的一些见解吗？
提前致谢。
答案 0 :(得分：9)
免责声明：这不是“不要使用存储过程 - 想想孩子们！”帖子，我不是要点燃火焰战。我只是建议重用代码比其他代码更容易，并且可能更适合某些情况和平台。
代码重用作为一个概念通常会改善代码库。你保留DRY并开始形成一层共同的功能，以同样的方式解决常见问题。
然而，就像任何事情一样，人们可能会犯错（权力来自责任等等等等）。
在大多数现代编程语言中，通过编写函数或甚至创建可以反复使用的整个框架来重用代码相对简单。但是，在T-SQL中它很棘手，因为你有更少的选项。存储过程可以做到，但你已经看到它们有多尴尬。
我个人的偏好是将业务逻辑保留在数据库之外。这意味着我不使用视图，UDF，sprocs等（除非在性能分析之后我们认为我们可以使用这些技术加速某些事情），而是将它保存在我的应用程序代码中。这通常会导致“业务逻辑层”的想法，但有各种各样的风格，所以它可能是用词不当。但它肯定不是直接在UI按钮点击处理程序后面的代码，等等。
我的目标是限制数据库存储和检索数据，因为这是他们真正擅长的。我们都知道笨拙和过时的T-SQL可以作为一种语言（想想异常处理，部署，游标等）。如果您的应用程序被写入数据库本身，并且您也无法扩展应用程序，那么与数据库无关是完全不可能的，因为数据库是应用程序。如果您在应用程序代码中具有该业务逻辑，则可以更容易地扩展它。
在这种情况下，“业务逻辑”是用于生成报告的查询和转换，我会研究在考虑其他选项之前如何在报告工具/代码中重用代码。
答案 1 :(得分：2)
TSQL中的代码重用需要根据具体情况进行。您需要养成检查所写查询的执行计划的习惯，以确定计划是否合理。
将视图连接到视图可以正常工作，或者根据其定义可能导致效率低下。
内联表值函数可以是重用代码的极好方法。它们避免了可能的谓词推送视图问题，并且当它们被查询优化器扩展时，它们允许您比使用多语句TVF或存储过程结果集更有效地对结果应用过滤器。
答案 2 :(得分：1)
代码重用的主要目的，IMO，是将单片程序分解为更容易理解和更容易维护的部分。分工不应该是特殊的 - 一个人对秩序的个人古怪想法。构建辅助函数库的艺术在很大程度上是一种社交艺术 - 您必须定义一个可理解的API，其方法是一致的。你不希望追随你的程序员在缺席的情况下诅咒你。您希望他们感谢您的设计的清晰度和实用性。
@Neil Barnwell：我认为将业务规则构建到数据库中没有问题。触发器和存储过程也可以执行此角色，如果不是比中间层或客户端代码更好。当然，你必须让程序员掌握数据库中的编程语言，T-SQL或PL / SQL或其他任何东西。