公司中有很多人说不要使用触发器,我想听听大家的意见.

如果对程序的控制和管理都很好的话还是可以用的，可是象我这里程序经常不同的人来做，的确也是不适合用这种东西

解决方案 »

  1.   

    这个问题和用不用外键差不多，主要看你的系统和开发组的要求
      

  2.   

    1. 第一个应该是软件工程的问题，和技术无关。
    2. 理由很模糊。“不可预期”？应该定义出specific的scenario，是同步问题，还是负载问题？这样比较容易讨论。
      

  3.   

    大量使用触发器之后，如果将来业务逻辑发生了变化，或者需要修改的时候，你会发现调试起来极其麻烦，很多时候出了问题都很难找出来，我曾经吃了大亏！以后如果不是非常必要的话我坚决不用触发器
      

  4.   

    存在就是有道理的,触发器在某些应用上能够灵活有效的对相关约束进行控制,当然,上述提到的两个问题是可以通过全面的文档及编程可靠性方面来解决的.
      

  5.   

    综合上面大家的意见,我总结如下.大家看是不是这样.1.如果说是开发一个产品,人员固定,文档齐全的情况下是可以使用的.
    2.如果是开发一个项目,在工期短,人员流动大的情况下则要避免使用触发器编程.
      

  6.   

    是啊，如果不是自己写的触发器，维护起来很麻烦的，特别是在文档还不太规范的公司。
      

  7.   

    1。如果能够使用约束实现所需要的功能，那么就不要使用触发器；
    2。如果可以使用存储过程实现所需要的功能，而且可以禁止用户直接访问你的表，那么就不要使用触发器；
      

  8.   

    刚开始没问题，然后就慢慢越写越多，在然后就是不知道哪对哪，再然后就是重写
      

  9.   

    后期维护起来不是太方便，尤其是对数据库有修改！
      

  10.   

    肯定有用处和好处!
    但不能泛滥!过犹不及!
      

  11.   

    没什么不可以用的,看公司的情况或个人的能力
      

  12.   

    我也比较倾向不用，特别有时涉及数据库转换的问题！
    能把人搞死，而且触发器也不利于以后修改。
      

  13.   

    如果可以的话
    用存储过程完成触发器的功能
    以后就调用存储过程用触发器到时候维护或修改程序时会很痛苦的
      

  14.   

    不用，在数据库迁移的时候就会有问题
      

  15.   

    看了一些回答，感觉如果程序分层，人员流动大也不好了？
      

  16.   

    大家都说不要用，还好我不知道这里所指的“触发器”是什么东西。