在Linq/Lambda（单元可测试但性能良好的存储过程）中编写存储过程。可能的

我正在为报表模型（SQL Server reporting Services）创建数据源。 这些报告需要大量的联接和计算（比方说，计算财务参数，比如花在这个、那个、金额a和金额B上的钱）……所有这些都涉及子对象

对我来说，为这段代码编写单元测试非常有意义（例如，遍历订单集合，根据业务规则和子对象聚合信息等） 为了正确地执行此操作，我希望我的代码看起来像这样

foreach (IOrder in Orders)
   foreach (IOrderLine in IOrder.Orderlines) 
     ...

   return ...

然后测试返回值

但是这段代码不是SQL，它将在reporting视图中使用…当然。。。 所以我想，我可以在数据库中插入一个.NET程序集。 当然，这里的问题是性能…我不想在C#中循环所有这些对象…太慢

因此，自然地，Linq/Lambda/Expression树似乎是我的答案。 我们知道，在执行Linq to SQL时，会构建表达式树，然后根据它们生成适当的SQL

因此，我可以使用lambda表达式在Linq to对象中编写代码，在样本集合上对代码进行单元测试（将表达式编译为.net），并在DB存储过程中重用与Linq to SQL相同的代码，以便在SQL Server中为我生成适当的SQL（就像Linq to SQL已经做的那样）

然后，我可以从单元测试和用C#编写域逻辑代码以及报告的高性能存储过程中获益

可能吗我可以在SQL Server CLR存储过程中使用Linq/Lambda吗？有人这样做过，或者知道如何使其工作吗？ 我疯了吗？你知道更好的方法吗

谢谢

p.S.我想现在我明白了应该如何正确地做这件事了。根据乌迪·达汉的说法，如果我理解正确的话。数据库应该非规范化，所有计算字段都应该位于表中的对象上。 当子对象（添加了医嘱行）上发生某些事情时，我的客户对象应该接收一个事件并重新计算智能值（缓存它并持久化）

---

然后，报告会直接进行，没有逻辑，工作速度很快……

不，您不能在SQL CRL过程中使用LINQ/Lambda-它基于不同版本的.NET，不支持这些名称空间

所以，我可以用Linq编写代码 对象，使用lambda表达式， 在示例上对该代码进行单元测试 集合（具有表达式） 编译为.net），并重复使用相同的 在存储的数据库中编码为Linq到SQL 过程，以便在SQL Server内部 它将为我生成适当的SQL （就像Linq到SQL已经做的那样）

在您建议从存储的进程中调用CLR代码之前，此计划是正常的。从数据库进程本身运行CLR代码会在版本控制、配置和数据库稳定性方面产生很多问题。。。如果你那样做，问题太多了

您的动机是获得使用存储过程的好处，这通常更快。如果这些存储的进程依次运行CLR代码，那么它们不会比本地进程中运行的CLR代码快

从技术上讲，使用LINQ生成的表达式比存储的进程消耗更多的CPU周期。这是因为每次运行查询时，数据库引擎都必须重新生成执行计划。通常情况下，您的数据库服务器位于一台独立的计算机上，尽管这台计算机不受CPU限制（它将受到磁盘或网络容量的限制），因此这不是一个真正的性能问题。如果您在与其他所有设备相同的机器上运行数据库服务器，可能会出现这种情况，但在出现真正的问题之前，不要尝试使用如此复杂的东西来解决此问题

如果您希望减少生成报告的开销，Udi的建议可能是合适的。首先要考虑两个重要的副作用。首先，您是否有能力增加预生成报告字段的操作的性能开销？一个更大的问题是，它将您的报告逻辑与运行目标系统的代码结合起来。这会阻止您在不更新业务代码的情况下更新报告代码，并假定报告代码一投入生产就正在运行