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