四、代码位置：数据库与中间层
通过在数据库中提供丰富的编程模型，CLR 集成提供了将逻辑从其他层移动到数据库层的选择。然而，这显然并不意味着所有或大部分逻辑应该移到数据库中。
将逻辑移到数据库层可以减少网络中的数据流量，但是增加了服务器上宝贵的 CPU 资源的负荷。因此，在应用程序中做出代码放置的决定之前，要慎重权衡。以下注意事项适用于将数据库层作为首选的代码位置：
数据验证：在数据层进行数据验证的逻辑可以更好地将数据和逻辑封装在一起。这样避免了在不同数据接触点（如：后端处理、批量上载和来自中间层的数据更新等）中重复验证逻辑。
减少网络流量：对于需要处理大量的数据而产生很少的数据的数据处理任务（如数据分析应用程序中的需求预测、基于需求预测的生产安排等）来说，将逻辑放在数据库层中是合适的。
注即使在引入 CLR 支持之前，上面的注意事项也是有效的。数据库层中的 CLR 支持意味着编程语言的选择没有妨碍代码位置的正确选择。
示例：生产安排
生产安排是制造企业的常见任务。在高层次上，它包括制订何时生产多少单位数量的产品的计划，以便能够满足需求、最大程度的降低库存成本，同时将生产成本降到最低。有几个算法将需求预测、库存成本和生产线安装成本作为输入，而将制造策略作为输出。
假定将来的需求预测存储在 SQL Server 表中，则此类算法的实现有以下特征：
1.
使用大量的数据作为输入（如需求预测）。
2.
产生小结果（如在特定的日期内生产的单位数量）。
3.
需要相当多的计算以便从输入中派生输出。
在中间层实现这样的算法是可行的，但是在数据库外移动输入集方面有性能损失。在 T-SQL 中将其实现为存储过程也是可行的，但是因为需要复杂的计算，性能损失就显现出来了。性能特征将随着实际的数据量和算法的复杂性的不同而不同。
为了验证 CLR 集成是否适合于这样的情况，我们举一个特定的生产安排算法的示例 － Wagner-Whitin 算法的动态编程实现。正如所预料的，CLR 集成优于 T-SQL。对于这种情况，使用托管代码还有其他好处。这种算法的实现需要使用大量的一维和多维数组、数据结构，而这些在 T-SQL 中是不可用的。总之，CLR 集成的性能要优于 T-SQL 实现几个数量级。
假定以下简单的数据库架构跟踪可以生产的产品列表。
下表存储了每周每个产品的需求预测信息。
给定一组产品，它们的库存和启动成本以及未来需求预测，我们创建了接受如下输入参数的存储过程：1)制订生产进度表的日期，2)按进度表生产所需要的周数。
存储过程返回带有下表中的架构的行集。
