34,590
社区成员
发帖
与我相关
我的任务
分享
...全文
请发表友善的回复…
发表回复
lionlsl 2004-07-11
- 打赏
- 举报
我非常同意" exu(大脸猫)"
但补允一点:
触发器尽量少做业务,就是说要写在服务器端.而存储过程要看系统是否对网速,安全有要求而定.
但补允一点:
触发器尽量少做业务,就是说要写在服务器端.而存储过程要看系统是否对网速,安全有要求而定.
xiaocuo_zrf 2004-07-11
- 打赏
- 举报
>> 是不是尽量多的在服务器端写存储过程和出发器
以前我也这样认为，但是后来真正实际应用发现有很多麻烦，很不理想，首先把业务逻辑分散的前后台都是，不方面维护和理解，其次，触发器给调试排错带来了很多的困难，第三数据库升级和跨越成了障碍，简直无法进行。维护成本太大。实在不宜大量使用，只能按情况使用。
以前我也这样认为，但是后来真正实际应用发现有很多麻烦，很不理想，首先把业务逻辑分散的前后台都是，不方面维护和理解，其次，触发器给调试排错带来了很多的困难，第三数据库升级和跨越成了障碍，简直无法进行。维护成本太大。实在不宜大量使用，只能按情况使用。
railgunman 2004-07-10
- 打赏
- 举报
我觉得比较复杂的操作和操作的数据量比较大的时候一般放在存储过程里，多写存储过程和触发器可以加快执行效率，但却减少了程序的可维护性和可移植性。
miszyf 2004-07-10
- 打赏
- 举报
如果是针对某个公司的系统，而且服务器性能很好，才会在服务器端写许多存储过程和触发器。
ddb0911 2004-07-09
- 打赏
- 举报
UP
exu 2004-07-09
- 打赏
- 举报
把大部分SQL写在服务器端的好处如下：
1、存储过程是预编译的，可以提高效率
2、减小网络流量：如果一个批量更新的SQL全部在客户端构建，网络流量大约比服务器存储过程高出50%以上（视复杂程度而定）。
3、可以增强数据库的安全性：这点非常重要！！！！你可以把表的权限关闭，而把存储过程授权给用户，可以最大程度的提高安全性
。。。
1、存储过程是预编译的，可以提高效率
2、减小网络流量：如果一个批量更新的SQL全部在客户端构建，网络流量大约比服务器存储过程高出50%以上（视复杂程度而定）。
3、可以增强数据库的安全性：这点非常重要！！！！你可以把表的权限关闭，而把存储过程授权给用户，可以最大程度的提高安全性
。。。
codehunter008 2004-07-09
- 打赏
- 举报
这要综合考虑！
1、可以减轻客户端的尺寸！而且界面和代码分离，为将来做准备！
2、减少网络流量，应该让服务器负担的就用服务器。
3、能一定的保证数据的安全性和保密行，甚至在存储过程中建立临时表写数据，完毕后在删除临时表！SAP就是这么做的，你看他的表结构甚至不能猜出都是做什么的！
1、可以减轻客户端的尺寸！而且界面和代码分离，为将来做准备！
2、减少网络流量，应该让服务器负担的就用服务器。
3、能一定的保证数据的安全性和保密行，甚至在存储过程中建立临时表写数据，完毕后在删除临时表！SAP就是这么做的，你看他的表结构甚至不能猜出都是做什么的！
metro 2004-07-09
- 打赏
- 举报
对于经常调用的一些功能，建议写在服务断。
LZGUI 2004-07-09
- 打赏
- 举报
尽量减少不必要网络的流量。
chaley 2004-07-09
- 打赏
- 举报
在數據庫端寫存諸過程有利於數據庫的安全性,不讓用戶直接操作表,交給存諸過程去操作.能很大成度的保掮數據庫的安全.這也是微軟的建義
huanyi 2004-07-09
- 打赏
- 举报
如果服务器的速度比较快，就尽量多的在服务器端写存储过程和出发器，
反之则少写，呵呵
反之则少写，呵呵
OldXing 2004-07-09
- 打赏
- 举报
这也不一定的问题.
要综合考虑.
如果你的数据库平台不更换and数据库性能强and业务复杂=>在数据库写业务逻辑.
反之写胖客户端
要综合考虑.
如果你的数据库平台不更换and数据库性能强and业务复杂=>在数据库写业务逻辑.
反之写胖客户端
jacket008 2004-07-09
- 打赏
- 举报
是不是尽量多的在服务器端写存储过程和出发器
非也
非也
IFindit 2004-07-09
- 打赏
- 举报
这要根据具体情况而定， 如果考虑以后的数据库更换的问题，最好就不要写了，再者也要综合考虑数据库的执行效率！
fenglaile 2004-07-09
- 打赏
- 举报
因为在客户端执行sql也要到服务器来解释和执行，使用存储过程则是在服务器端已经解释完毕（编译过),所以执行速度相对要快些，并且好统一管理
