提出一个疑问
一直在做进销存二次开发，发现关于业务中算金额，每次都需要写很复杂繁琐的存储过程（用的SQL Server），经常出错而且很难找出错误，每个存储过程都很长，很多都在二、三百行。我有个想法是，业务逻辑能不能交给C#代码去处理，而存储过程只负责查询？就是说查出来之后，在C#中计算金额，这样会影响执行效率吗？
------解决方案--------------------
可以，是否影响效率看你怎么写，尽可能把数据的筛选、分页、分组、连接这些放在数据库端，其余放在程序中。
------解决方案--------------------
顶起来，等待继续讨论~
------解决方案--------------------
两种做法各有各的好处，主要看业务需求和系统规模。
如果需求变动比较频繁，将逻辑统一写在存储过程中维护起来会比较简单（不用重新编译程序），另外从出报表的层面看，使用存储过程比较灵活。

------解决方案--------------------
主要是有些东西是会变的,特别是计算公式上边,不可能每次都编译一个版本的软件,然后通知所有用户去更新,所以一般将特别复杂的运算放到存储过程里面,以后要改规则改公式就只是单存改存储过程就可以了,就可以省去编译和升级的风险
------解决方案--------------------

引用:

我觉得他的意思应该是如果业务变动，则可以直接修改SP给用户，而不用重新发布，但是这个SP里面写业务,SQL实在是太复杂了

我们那前些年流行的“三层架构”来说，最初的三层概念来自于c/s架构网络，也就说具有“应用服务器”挡在数据库服务器之前。任何大一点的系统都是如此，例如任何一个网游系统、电商系统之类的。

可是被一些人烂改概念，那些只会做小办公室里的小软件（只会拿一个关系数据库的客户端驱动去访问数据库）也号称自己的是c/s系统；一些在单进程简单程序里也繁琐地“为了三层而三层”地搞什么手工编写一大堆DAL代码之类的的做法也号称自己是“三层架构”。

你只有跳出这种开发团队，才会发现原来别人是那样区分层次的。
------解决方案--------------------
lz 所说的方式的确可以。但是与在存储过程中实现没什么大的区别。区别就在于编写程序的需要多花点功夫。写存储过程的少花点功夫。至于开销和复杂度是完全谈不上的。因为开销最后会计算到客户头上。自己的产品别人也不差这么点钱。复杂度 在存储过程中计划和程序计算没什么大的区别。维护的确是很容易维护 随时远程进服务器修改 存储过程公式  是挺容易维护的。而更改程序 需要环境打开源代码 进行多方面测试后才能发布。。重这方面的角度来说 你公司 开发团队是有一定的道理的