sql - 我使用 SQL UDF 来封装简单的报告/业务逻辑。我应该避免这种情况吗？

Question

我正在 SQL Server 2008 中为某些报告构建一个新数据库，并且有许多与这些数据相关的常见业务规则进入不同类型的报告中。目前，这些规则大多以传统语言结合在较大的过程程序中，我正在尝试将其转移到 SQL。我正在寻求根据这些数据实现报告的灵 active ，例如 SAS 中的一些报告、C# 中的一些报告等。

我目前的方法是分解这些通用规则(通常非常简单的逻辑)并将它们封装在单独的 SQL UDF 中。性能不是问题，我只是想使用这些规则以某种报告“快照”的形式填充静态字段，然后可以使用它以您想要的任何方式进行报告。

我喜欢这种模块化方法，因为它可以理解每个规则的作用(并维护规则本身)，但我也开始有点担心维护也可能成为一场噩梦。有些规则取决于其他规则，但我无法真正摆脱它 - 这些东西相互依存......这就是我想要的......我想？ ;)

数据库中的这种模块化方法是否有更好的方法？我是否走在正确的轨道上，或者我是否以太多的应用程序开发心态来思考这个问题？

Answer 1

在某些时候，广泛使用 UDF 将开始导致性能问题，因为它们是针对结果集中的每一行执行的，并且模糊了优化器的逻辑，从而很难使用索引(即，我真的不明白性能如何可能不是问题，但您最了解您的要求)。对于某些功能来说，它们非常棒；但请谨慎使用。