大型系统是否必须具有存储过程和触发器？

从存储过程到外部应用服务器的所有逻辑是否真的减轻了的压力？

应用程序服务器需要管理以连接到应用程序服务器以发送SQL，SQL可能是多个批处理到，以便动态处理SQL响应数据并返回到应用程序服务器. 根据转换后的语言数据重复上述步骤，进行逻辑商务旅行，确定分支循环，等等.

压力是增加还是减少？整个系统的吞吐量是大还是小？如果在存储过程中执行集成处理，则网络往返成本，序列化和解析成本，网络数据响应和过程交换成本将降至最低.

我认为通用概念是错误的. 解决压力的方法是不使用存储过程，但事实恰恰相反:

以前的朋友提到过存储过程在解析，提交和网络方面的性能优势. 这里没有重复. 压力通常很高. 通常需要DBA来帮助应用程序开发人员进行优化. 少数代码或物理结构通常是不合理的. 很大一部分负载存储过程本身直接编写业务逻辑. 那些if-else-then，for-loop等实际上仅在负载方面处于领先地位. 将其带到外面根本不会减轻的负担. 负载，在网络处理，格式分析和转换等方面花费了多少. 可以将多少转移到存储过程的开销中？

我所听到和遇到的不是存储过程的原因. 部分原因是因为我对了解不多，但更多是因为黑白颠倒了. 1.我不知道存储过程何时会失败. oracle存储过程自动依赖于管理. 如果从属表和其他存储过程被更改，则存储过程将自动变为无效. 但是，下一次执行将自动重新编译，而不会影响使用，我们也可以手动重新编译. 因此，失败根本不是问题，而是编译时的可靠机制.

2. 业务需要跨多个库集成事务访问. 使用dblink时很容易出错. 您只能使用tx-monitor和其他tp-monitor来处理dblink. 您不能选择专用模式，可以选择共享模式或驻留池模式，否则将导致大量链接到对等并启动大量服务进程，从而导致性能和资源不足. 这是可以避免的. 使用dblink可以支持全局事务或分步事务，而无需使用tp-monitor. dblink请求和响应的内容应尽可能小. 不要进行跨表关联. 与使用tp-monitor相同.

3. 信息系统的负载压力始终在上，因此不要再对它执行存储过程，无论使用哪种体系结构，SQL恐怕都无法承受已经分析的结果向请求这也是必不可少的. 您在外面写逻辑. 您对的压力可能与编写存储过程的压力相同. 不要以为太简单.

4. 为此，牺牲分层设计和系统维护是不合理的. 与使用Java等语言的SQL或ORMapping相比，存储过程更易于编写.

5. 调试很困难. 编写存储过程，无需强迫您处理传统应用服务器上出现的问题的细节. 您可以直接集成SQL并进行一些逻辑处理. 基本上，您不需要特殊的调试. 如有必要，plsql Developer IDE也支持单步调试或其他方式.

6. 迁移的困难首先，为了确保可以在不同的关系之间迁移，您只能使用其特性的交集. 一些比其他更昂贵的原因之一就是因为它们具有更. 包括发展. 如果可以使用存储过程轻松开发应用程序存储过程与触发器，那么为什么还要编写应用程序服务器代码呢？同样，如果您确实要迁移，则还应该使用目标的存储过程来封装主组的业务逻辑. 第三，即使将体系结构设计为完全可迁移的，真正的迁移也确实敢于为大型或关键信息系统实现，但99％的人不会冒险. 第五存储过程与触发器，对于需要向外界提供接口服务的地方，外层通用协议（http）的外壳就足够了. 库外壳的接口未更改，并且内部存储过程参照原始存储过程重写.

7. 书写存储过程不舒服

引用别人的话，“许多新手不喜欢存储过程的原因是他们不写或不熟练，这太麻烦了. 相反，他们可以使用编程语言逐行堆积业务逻辑. 行. ”

但是使用存储过程有一些缺点.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-196592-1.html