首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 网站开发 > asp.net >

提出一个疑义

2014-05-14 来源:读书人网 【读书人网(Reader8.cn):综合教育门户网站】
提出一个疑问一直在做进销存二次开发,发现关于业务中算金额,每次都需要写很复杂繁琐的存储过程(用的SQL Se

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

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

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

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

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

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