存储过程和触发器的必要性，以及ERP系统模块化问题(300分)

我接手了一个性质类似于ERP的系统，平台是asp+sqlserver
前一个版本由于历史原因，考虑得不是很周全，
而且经过多次补丁，代码已经变得很混乱
公司希望我能按照代码复用原则重写整个系统
这几天一直在做系统分析和写文档
在是否大量使用存储过程和触发器的问题上，我和同事发生了分歧
从我的经验来看，我倾向于使用，但我觉得对方的一些观点也是有道理的
在这种系统中，大量使用存储过程和触发器
到底是应该提倡的还是应该避免的？
使用它们到底是符合模块化的要求，还是违反？
存储过程和触发器是符合潮流的呢，还是将被淘汰？
还有，对这种系统进行模块化，有什么原则、经验、教训？
适合使用什么技术？
请在这方面有经验的朋友发言，谢谢。

模块化时，基础模块的功能要尽量的单一（好像一个函数一样），由别的模块来继承或者uses，
当基础模块中的功能不能满足需求时，在他的继承模块中采用重构的方式来扩展。这样，最内部
是几个基础模块，外面包围的是一些简单的扩展模块，再外面是一些更加复杂的扩展模块。
最后，你的所有级别的模块就都可以被相应的重用，觉得哪一级不满意就更改那一级，他外部的
继承模块的功能也会同时更新，而不必改动每一个模块。

您对模块化的定义很正确
但对解决我的问题并无帮助:-(

存储过程是两层到三层之间的一个过渡产品，以前没有三层技术架构，
客户端非常胖。使用存储过程可以在一定程度上封装业务逻辑，减轻
客户端的升级难度，并提高系统的运行效率。
但存储过程用多了之后非常不利于数据库的移植，曾经有一个项目因为
使用了过多的存储过程，最后发现要移植到Oralce（原为Infomix）上
花的费用比重做一个系统还大，最终放弃了移植系统的方案，所以你的
项目如果需要兼容多种数据库的话，建议少用或尽量不用存储过程。
我以为最好将业务逻辑放在中间层，不要直接放在DB上。

>>

我们头就反对我们使用存储过程
说移植的时候不方便

该用地时候就用，不该用的时候就不用。[][][]

用脚本作erp恐怕需要做不少组件。。
多想象类的设计，比proc要好。。。

我很同意帥哥的觀點與說法！移植性是DB的一個最關鍵的問題，
因此你應該為你的系統往後的發展作一個全面的考慮，作為一個通用
的系統來講，DB的移植對系統的維護是個關鍵所在，我個人認為存儲過程
適當的使用有所幫助，但觸發器最好盡量少用，我可是害怕這個東東。

从代码复用的角度讲，保留复用存储过程和触发器很有必要，另外使用存储过程和触发器并
没有违反模块化原则，相反它对优化系统有相当的作用，在一段时间内仍是主流。

Listen...

我一个上市公司的客户关系系统
也是ASP+sqlserver

从实用角度上来讲,
如果是应用程序,我是不会用存储过程的,因为客户端拥有大量系统资源,
很多过程都可以在客户端来做,
充分利用了资源,

但是ASP嘛,本身的稳定性就有一定问题,
如果在访问量不大的情况下,用存储过程和触发器可以弥补这个不足,
在客户端只做一些数据的接收和验证工作,

还是具体问题具体分析,
实事求是为原则

我目前用JSP+JAVA+SQLSERVER作产品，
因为面对不同用户，所以选择的数据库有多种，一般的库操作，都统一做成了CLASS，
如作存储过程的话，每个数据库的总会有自己特色，难免会发生意外，是好的方法就是
通过中间层来解决。
象我现在SQLSERVERR 已做完，现正在改成ORACEL的，我只要在CLASS中做个CASE就全搞定
把SQLSERVER的一些不同于ORACEL的东东，改一下就行了。

存储过程和触发器以降低移植性为代价，却增加开发效率和执行效率。
在ERP中要大量传递数量、金额、状态的改变，触发器是首选解决方法。
但是对于存储过程，我认为除非特别注重效率，尽量用客户端实现。
其实我觉得做好存储过程和触发器的文档化工作，移植起来也不是太大问题。

听课来了

為什么不用?
難道你們還打算把sql server上的sql server SQL語句移植到Oracle﹐變成ANSI的SQL語句嗎?

你用asp開發﹐我想不是ERP吧﹐應該說是CRM﹐如果真有人用asp來開發整個erp﹐我倒是想見識見識?

我以前做c/s结构的进、销、存是大量的使用procedure
现在有考虑！
我现在编的程序200多个表，只在生产管理中用了8个procedure,
而且是用在用户使用最频繁的地方，这样性价比较高！
我以前用asp做是，如果写procedure,一般也是采用这种原则，而且是用vb写组件来调用
即asp+server(IIS)+asp组件（比较好用事务处理）+sql Server

找一个用友网络财务版 v9.0
好象是jsp 的

存储过程和触发器的必要性，是要根据我们系统的具体情况来决定是否使用,而不是根据什
么提倡使用或不使用来决定,如果你公司的数据库在未来更改数据库的可能性很小,而且你
使用触发器带来的效率有很大的改善,那么你可以考虑使用触发器和存储过程,如果以后有
可能更改数据库系统,而且如果改写存储过程的话,所带来的后期成本很高,大于你现在开发
的成本,那么当然就不要用存储过程.
我的建议是:自己先期算一下,将使用和不使用带来的好处和坏处都列出来,各种可能都算出
来,折算成大致经济成本和效益,就知道到底要不要用,也有说服你同事的理由了.如果我们
都根据书上说的尽量不使用存储过程,那么为什么数据库中还有存储过程呢?因为它们毕竟
能带来比较高的效率,使用得当,就会给你带来极大的好处,使用不当,就会带来后患无穷.所
以,左大哥还是要自己算一下最好,自己的情况自己最清楚.
模块化方面,我就不说了.[]

听...

左轻侯,这是我总结的，你看了应该就明白了。
========================================
优化数据库的思想：
================
1、关键字段建立索引。
2、使用存储过程，它使SQL变得更加灵活和高效。
3、备份数据库和清除垃圾数据。
4、SQL语句语法的优化。（可以用Sybase的SQL Expert，可惜我没找到unexpired的序列号）
5、清理删除日志。

SQL语句优化的原则：
==================
1、使用索引来更快地遍历表。
缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在
对各种查询的分析和预测上。一般来说：①.有大量重复值、且经常有范围查询（between, >,< ，>=,< =）和order by、group by发生的列，可考
虑建立群集索引；②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定
是使用最频繁的列。
2、IS NULL 与 IS NOT NULL
不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从
索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is null或is not null的语句优化器是不允
许使用索引的。
3、IN和EXISTS
EXISTS要远比IN的效率高。里面关系到full table scan和range scan。几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。
4、在海量查询时尽量少用格式转换。
5、当在SQL SERVER 2000中，如果存储过程只有一个参数，并且是OUTPUT类型的，必须在调用这个存储过程的时候给这个参数一个初始的值，否则
会出现调用错误。
6、ORDER BY和GROPU BY
使用ORDER BY和GROUP BY短语，任何一种索引都有助于SELECT的性能提高。注意如果索引列里面有NULL值，Optimizer将无法优化。
7、任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
8、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。
9、SET SHOWPLAN_ALL ON 查看执行方案。DBCC检查数据库数据完整性。DBCC(DataBase Consistency Checker）是一组用于验证 SQL Server 数据
库完整性的程序。
10、慎用游标
在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，这样可使性能得到明显提高。
总结：所谓优化即WHERE子句利用了索引，不可优化即发生了表扫描或额外开销。经验显示，SQL Server性能的最大改进得益于逻辑的数据库设计、
索引设计和查询设计方面。反过来说，最大的性能问题常常是由其中这些相同方面中的不足引起的。其实SQL优化的实质就是在结果正确的前提下，
用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是
在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。