【讨论】关于数据层用不用存储过程封装的问题？

mucang001

从第一页看到最后一页  受益匪浅，没有对没有错 只有哪个更适合需求，谢过。

solomon_007

反对用PLSQL存储过程的人，基本上是对这个东西不够熟悉，从而形成了那根深蒂固的错误思想！！

不知不觉中，已经成为了阻碍生产力发展的守旧派，顽固派，绊脚石，垃圾和大SB！！！！

newkid

solomon_007 发表于 2012-12-3 14:34
反对用PLSQL存储过程的人，基本上是对这个东西不够熟悉，从而形成了那根深蒂固的错误思想！！

不知不觉中 ...

哈哈，虽然我也是存储过程的粉丝，但觉得你这样批判有点过了。

solomon_007

newkid 发表于 2012-12-4 00:18
哈哈，虽然我也是存储过程的粉丝，但觉得你这样批判有点过了。

yulihua49

solomon_007 发表于 2012-12-3 14:34
反对用PLSQL存储过程的人，基本上是对这个东西不够熟悉，从而形成了那根深蒂固的错误思想！！

不知不觉中 ...

回到楼主议题，不是什么都必须存储过程，也不应该禁用存储过程，我的观点是因地制宜。
我现在的这个系统就是混和的。大量工作是存储过程，只有核心的一点点功能是OCI的。
几十人的团队，只一两个人做OCI。

newkid

yulihua49 发表于 2012-12-7 17:04
回到楼主议题，不是什么都必须存储过程，也不应该禁用存储过程，我的观点是因地制宜。
我现在的这个系 ...

你这个所谓的“核心”功能是什么？数据清算？
如果是文件加载卸载，那不算什么核心。

yulihua49

newkid 发表于 2012-12-8 00:20
你这个所谓的“核心”功能是什么？数据清算？
如果是文件加载卸载，那不算什么核心。

哈哈，在这里就不必谈具体业务了。
一组数据，来自文件，经过计算，装入数据库，供下一道工序使用。
广义的，就是数据加载。那个计算是核心，也就是清分系统核心部件，不过那个不归我管，我只管数据的接收、分配和加载。
那个计算过程需要查询一些表，我把它放到内存，提供一些查询功能而已。本帖61楼啊。
只有这个部分是C的，其它都是存储过程。
我的意思，一个系统，只需很少的人玩C，大部分玩存储过程。
就是，不要禁止存储过程，也不要一味存储过程，要因地制宜，需要什么用什么。
事实是，C的部分被压缩到极小，如果对性能没有特殊需求，可以不用它。
不过我还是这个观点，不太复杂的逻辑可以PL/SQL，太复杂的还是要编程语言，可能是C。

newkid

yulihua49 发表于 2012-12-8 20:48
哈哈，在这里就不必谈具体业务了。
一组数据，来自文件，经过计算，装入数据库，供下一道工序使用。
...

说错了，PL/SQL根本不怕复杂，有时候用它解决复杂问题用的代码更少。参见我们最近的感恩节编程比赛。
如果是大量的纯内存算法、或者涉及到数据库之外的数据，C有可能在速度上占优势，但用的代码一点也不会少。

gyj_hobby

yulihua49

newkid 发表于 2012-12-8 22:56
说错了，PL/SQL根本不怕复杂，有时候用它解决复杂问题用的代码更少。参见我们最近的感恩节编程比赛。
如 ...

复杂，不是说代码长度，主要是逻辑的复杂度，和有关执行时间方面的问题。
感恩节问题，等我有空了学习学习，琢磨琢磨。
我最近的这个项目，经过几番改进，代码越来越长。速度已经从原来的30分提高到18分。在正试运行的系统上实现了2分10秒的成绩。
这些代码多数用于多机，多线程的资源管理，各个工序资源需求平衡（各级队列和线程池、连接池，负载均衡的管理等等）。
就是说，大量代码根本就不是直接处理数据的，而是管理数据的流量流向的。
还有前边说过的，一些表放在内存，自己写检索程序，这当然很麻烦，比写SQL代码多多了，但它为我们赢得了时间。
比如，查询一次运行图（时刻表），SQL需要至少100微秒，内存查询3微秒，每个交易平均查询100次，加上其它的处理，平均每个交易500微秒，而且是纯计算，没有IO，完全可以通过多线程充分的并行化。而SQL呢？不仅慢，而且伴随大量IO（磁盘的，网络的），很难充分的并行化。

就是说，当需要更多的系统资源和机制时，就需要采用某种系统语言代替数据库语言。