MySQL自从5.0版开始引入存储程序,开始向商业RDBMS系统迈向重大的一步。
存储程序包括三大主要类型:Stored procedure、Function和Trigger
使用存储程序的优势:
1,更安全
2,抽象数据访问程序,改进可维护性
3,减少网络开销
4,多个程序或框架不兼容时用于实现常见程序
5,数据库为中心的逻辑可以隔离在数据库里由专业数据库程序员开发
6,有时可以改进移植性
但是也不是什么地方用存储过程都是好的,凡事都有个度的问题。
大量的业务逻辑程序就是存储过程干的。除了调试不方便外,用存储过程业务法满足跨数据库的需要,今天A客户用ORacle,明天B客户用sybase。这个问题如何解决?
另外大量采用存储过程进行业务逻辑的开发致命的缺点是很多存储过程不支持面向对象的设计,无法采用面向对象的方式将业务逻辑进行封装,从而无法形成通用的可支持复用的业务逻辑框架。
不过,在对性能影响较大的时候在局部采用一个存储过程也可以的,但是目前几乎很少碰到性能到了用户无法接受情况。有些系统大量采用了存储过程,由于对游标等对象操作不当,导致系统整体性能不佳的情况框也很多。上千行乃至几千行的存储过程在这些系统中比比皆是,最后导致很难维护。
用不用存储过程,主要从网络传输和性能以及产品对象是否需要数据库移植方面考虑。
把存储过程用在适合使用的地方~~
存储程序包括三大主要类型:Stored procedure、Function和Trigger
使用存储程序的优势:
1,更安全
2,抽象数据访问程序,改进可维护性
3,减少网络开销
4,多个程序或框架不兼容时用于实现常见程序
5,数据库为中心的逻辑可以隔离在数据库里由专业数据库程序员开发
6,有时可以改进移植性
但是也不是什么地方用存储过程都是好的,凡事都有个度的问题。
大量的业务逻辑程序就是存储过程干的。除了调试不方便外,用存储过程业务法满足跨数据库的需要,今天A客户用ORacle,明天B客户用sybase。这个问题如何解决?
另外大量采用存储过程进行业务逻辑的开发致命的缺点是很多存储过程不支持面向对象的设计,无法采用面向对象的方式将业务逻辑进行封装,从而无法形成通用的可支持复用的业务逻辑框架。
不过,在对性能影响较大的时候在局部采用一个存储过程也可以的,但是目前几乎很少碰到性能到了用户无法接受情况。有些系统大量采用了存储过程,由于对游标等对象操作不当,导致系统整体性能不佳的情况框也很多。上千行乃至几千行的存储过程在这些系统中比比皆是,最后导致很难维护。
用不用存储过程,主要从网络传输和性能以及产品对象是否需要数据库移植方面考虑。
把存储过程用在适合使用的地方~~