|
查看: 1175|回复: 11
|
应不应该用stored procedure (高手请进)
[复制链接]
|
|
|
发表于 29-11-2008 12:43 AM
|
显示全部楼层
某些 Stored Procedure 还是需保留的, Stored Procedure 在 multi-user system 真的是非常好的。
3 Tier 只是将 buisnesslogic 和 UI 分开罢了。。 |
|
|
|
|
|
|
|
|
|
|
发表于 27-12-2008 09:17 AM
|
显示全部楼层
如果你的系统是一个product,那就写在business layer, 可以cater multiple databases, deployment 也是一次过. 通常java developer 会用这个pattern,丢整个war file 就可以了,他们用hibernate 来取代stored procedure. DotNet 就是 nhibernate, linq to sql 和 linq to entity. 丢dll file.
没有人讲用stored procedure来写logic是错。这是看你的。要看你的客人喜欢换database table还是user interface和requirement.
原帖由 siaolee2000 于 28-11-2008 11:23 PM 发表 
在一个3-tier的系统里面,是不是所有的business logic应该都写在application server里面,而database server只是用来储存资料。如果是那样的话,用stored procedure来写logic这个方法不是错了? |
|
|
|
|
|
|
|
|
|
|
发表于 3-12-2008 12:17 AM
|
显示全部楼层
原帖由 tensaix2j 于 29-11-2008 10:07 PM 发表 
而且,你的 stored proc是否很database specific 呢? 假设某日要换别的 db 的话,可以吗?
我想SP最大的问题就在这里,Business Logic在SP里,当要Migrate DB,那就要跳楼了
近期刚开始处理一个application, 90%+ 的Business Logic 都在SP里,真是要吐血 |
|
|
|
|
|
|
|
|
|
|
|
在一个3-tier的系统里面,是不是所有的business logic应该都写在application server里面,而database server只是用来储存资料。如果是那样的话,用stored procedure来写logic这个方法不是错了? |
|
|
|
|
|
|
|
|
|
|
发表于 28-11-2008 11:54 PM
|
显示全部楼层
原帖由 siaolee2000 于 28-11-2008 11:23 PM 发表 
在一个3-tier的系统里面,是不是所有的business logic应该都写在application server里面,而database server只是用来储存资料。如果是那样的话,用stored procedure来写logic这个方法不是错了?
通常involve 很多table 如 batch processing 和 reporting 用store procedure 比较好。
在application server 里要open connection close connection 很多次,很浪费resources.
还有CMP BMP 都有timeout 的问题
和你select 一个很大的table 然后放进 vector里,也很eat resources |
|
|
|
|
|
|
|
|
|
|
发表于 29-11-2008 10:07 PM
|
显示全部楼层
|
而且,你的 stored proc是否很database specific 呢? 假设某日要换别的 db 的话,可以吗? |
|
|
|
|
|
|
|
|
|
|

楼主 |
发表于 29-11-2008 08:21 PM
|
显示全部楼层
|
将business logic写在stored proc,那如果以后顾客有不同的business requirement的时候,岂不是每次都要再改stored proc? 如果是写在application server的话,是不是可以用windows workflow foundation之类的技术,那我们就不需要recompile source code,也不需要改stored proc。而且如果是将所有logic写在application server,那以后换db就不需要再写过stored proc,你们认为如何? |
|
|
|
|
|
|
|
|
|
|
发表于 3-12-2008 03:09 PM
|
显示全部楼层
原帖由 sfkwan 于 3-12-2008 12:17 AM 发表 
我想SP最大的问题就在这里,Business Logic在SP里,当要Migrate DB,那就要跳楼了
近期刚开始处理一个application, 90%+ 的Business Logic 都在SP里,真是要吐血
我也是一样
要 convert MSSQL 的 stored procedure, trigger & job 去 Oracle
要吐血了 |
|
|
|
|
|
|
|
|
|
|
发表于 7-12-2008 12:18 AM
|
显示全部楼层
通常我会分成3个layer:
Presentation Layer
Business Logic Layer
Data Access Layer
Stored procedure是属于data access layer的东西,所以通常不会把business logic写在里面。
只有在做reporting的stored procedure会需要一些logic。 |
|
|
|
|
|
|
|
|
|
|
发表于 17-12-2008 01:30 AM
|
显示全部楼层
|
|
|
|
|
|
|
|
|
|
发表于 27-12-2008 03:36 PM
|
显示全部楼层
回复 10# woaychee 的帖子
|
你好,我想问如果用hibernate来取代一个join几个tables的SQL,performance会不会慢? |
|
|
|
|
|
|
|
|
|
|
发表于 27-12-2008 07:05 PM
|
显示全部楼层
老实一句,stored procedure 永远比 那些写在application pass 进来database 的快。
如果你有design一些application. 1 tier application 永远比 2/3/4/5 tiers application快。 但是,你要maintainable 还是要快,你选。
原帖由 alexleong 于 27-12-2008 03:36 PM 发表 
你好,我想问如果用hibernate来取代一个join几个tables的SQL,performance会不会慢? |
|
|
|
|
|
|
|
|
| |
本周最热论坛帖子
|