|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (13)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-03-18
存储过程不好维护,还是用程序比较好,而且效率也不是很低啊
|
| 返回顶楼 | |
|
最后更新时间：2008-03-19
在执行效率上，存储过程的确很快，较为复杂的业务逻辑及海量的数据，为了提高性能适合使用存储过程。但数据量不太大，需求变更较多的项目，就需要将业务逻辑放在java应用层来实现，使用的技术要看项目的具体情况，具体分析。
|
| 返回顶楼 | |
|
最后更新时间：2008-03-19
每个人的观点都有道理，自己选择哦
|
| 返回顶楼 | |
|
最后更新时间：2008-03-20
我觉得应该业务和数据分离，也就是说业务逻辑应该在service中去做，不要牵扯数据库，尽管存储过程效率高，但那也不应该成为用数据库来处理业务逻辑的理由
|
| 返回顶楼 | |
|
最后更新时间：2008-03-20
业务逻辑都在数据库服务器了，要应用服务器作什么？委托？
|
| 返回顶楼 | |
|
最后更新时间：2008-03-20
业务逻辑都在数据库服务器了，要应用服务器作什么？委托？
|
| 返回顶楼 | |
|
最后更新时间：2008-05-06
互联网是以“读”为主的应用，可以写在中间层，利用缓存和群集，数据库基本上很少读，效率高。这类应用可以写在中间层。
企业是以“写”为主的应用，缓存基本无用，要想效率高，最好是写存储过程。 |
| 返回顶楼 | |
|
最后更新时间：2008-05-06
ian jiang 写道 当开发中的业务逻辑既可以在数据库中完成（例如，使用oracle的function）,也可以在java的service层中完成时，我们应该依据什么样的标准来进行选择?各自可能的优点和缺点有那些?
如果可能换语言，或不同语言开发的模块都要用的业务逻辑，就写到数据库 如果可能换数据库，就写到service层 |
| 返回顶楼 | |
|
最后更新时间：2008-05-23
lgx522 写道 互联网是以“读”为主的应用，可以写在中间层，利用缓存和群集，数据库基本上很少读，效率高。这类应用可以写在中间层。
企业是以“写”为主的应用，缓存基本无用，要想效率高，最好是写存储过程。 实际中似乎正好相反，你去问问sina，yahoo的人，他们作大规模的业务系统大多都要用存储过程（数据量太大，同时对性能要求比较高）。 而一般的“企业应用”处理的数据和并发都比上边的要小几个数量级，反倒多用中间层处理逻辑。 |
| 返回顶楼 | |
|
最后更新时间：2008-05-23
我用存储过程只有一种情况：SELECT数据 时才用
|
| 返回顶楼 | |
