关于【存储过程】和【触发器】在项目中是否滥用的请教和讨论。

Question

触发器很少用...不过sp..........好像从来都没有在程序中写过一条sql语句.....全是过程......至于移植问题......我觉得不是很棘手吧....呵呵...本人低手.....听大侠来发表评论

Answer 1

开发要看多方面。要总体的去看。
如果你技术低的话。在公司基本上很难有发言权。
我们大部分是实现在代码？并非SQL Server。
还要看你的数据库的访问量。
如果是很大的话。还是多一点存储过程。

Answer 2

在微软Duwamish的例子里，数据访问层几乎全部通过存储过程来实现。是否可以说在一个项目里，对数据库的数据访问层实现要么全部采用存储过程,要么全部不用？在数据访问量不大的情况下..........听听大家的高见。

Answer 3

个人一点意见：
 比较复杂的数据库操作，例如其中有大量运算的，采用存储过程，简单的sql语句就不  用 了。说存储过程的效率高，我想也是体现在复杂大量的运算中，简单的sql语句怕是差别不大

Answer 4

触发器有可能导致性能下降，要权衡使用，至于SP，基本上都是大量使用:)
如果要移植，我觉得一开始就应该作基于不同DB的设计，就像PetShop那样

Answer 5

我以前对触发器和存储过程的使用比较抵制，不到万不得已我是不会轻易使用它们的。但经过大家的讨论，使我改变了自己对它们的偏见。不过我想再发表一下自己的一些肤浅的看法，求高手帮分析一下。我觉得如何使用触发器和存储过程应该根据软件项目具体情况的不同，而不同考虑。这些包括：软件的规模大小、
业务规则复杂程度（或运算复杂程度）
数据吞吐量、
数据的运算强度、
数据处理响应时间、
运行环境(包括网络环境、数据库服务器、应用程序服务器和客户终端的性能）
系统分布式结构等情况来加以考虑。因此在哪一环节处理什么样的数据,在性能上要考虑到运算负载平衡、数据网络传输效率，在代码的效率和质量上要考虑代码的可维护性和复用性。没有最好的、只要较好的选择。触发器和存储过程的使用可以大大的降低网络的负载，Sql语句已经预编译过，在低强度的运算处理中可以大大的提高系统的性能。但是DBMS（包括相关的服务器平台）是专门针对数据的存储、检索设计，不适合做大强度的数据运算，而且代
码的维护性低。特别是触发器用它来处理复杂业务逻辑，数据的关联更新在数据库里面满天飞的时候，简直就是没有维护性可言。如Duwamish的例子中，存储过程主要就是提供数据的保存和检索。
  有时候客户的业务系统很小，但数据库服务器的配置很高，远远超过了业务数据运算处理的要求，那么就不需要考虑太多的运算负载平衡了。如果网络环境速度够快，业务数据量又少，也不需要考虑太多的网络负载平衡。我通常喜欢在不影响网络传输速率的情况下，尽可能的把业务数据的处理放在客户端或应用程序服务器，应为代码易于维护,而且可以平衡一下运算的负载。我曾经接手一个别人用存储过程开发好的报表程序，其中有一个报表特别复杂，大强度的运算和统计生成需要6个小时，所以必须每天在晚上执行，然后保存到一个临时表中。最要命的是这个报表经常变动，代码又多又难调试。后来我就用Delphi+sql语言重写那个报表，并且在另一台应用程序服务器中定时晚上运行。速度没有慢多少，但是代码好维护多了，必尽Sql不是OOP的语言。所以我认为尽可能的考虑软件的稳定性和可维护性，而系统体性能是次要的,只要在客户可以忍受的范围内。

Answer 6

一般的操作用sql语句就足够了，但如果数据调用频繁或涉及到效率问题的换还是用存储过程好

Answer 7

难得糊涂啊!
真糊涂------>真明白-------->装糊涂这就是我走过的路.

Answer 8

绝对使用存贮过程，
第一，可以提高数据库服务器查询、处理或存贮的性能，减少网络数据流量。
第二，减少程序员写出一些非专业的SQL脚本，造成BUG或全表扫描。
第三，存贮过程在移植时，可能更为方便，在数据库性能调整时，也更为方便。
第四，分工明确，系统在功能分层上也很清晰，维护方便。
触发器
建议多使用
第一、可以在数据库级的保证数据的完整性。
第二、更有效的减少网络数据流量。
第三、逻辑清晰，并不需要所有程序员都明白之间的约束，各做各的。这些东西，我自已觉得没有理由不用，连我自己写小程序时，基本都用。

Answer 9

比较认同gujunyan(ivy阿亮)对存储过程的看法，对触发器不敢雷同，应为我们公司是小的软件开发公司，没有专门的DBA。

Answer 10

有一点是可以肯定的，就是存储过程在数据的存储和检索上的使用是Good选择。