触发器作为保持数据一致的机制可信任吗？
如题，如果在触发器起作用的时候发生宕机、数据库断开等等意外的时候，数据就不能保持一致了吗？MSSQL有没有相应的恢复机制？是不是触发器的条件全部改成instead of 才是安全的？
主表a，从表b，资源表c，以下哪种方案比较好？
方案1：应用程序更改abc，然后事务提交（应用程序更新c复杂度大增）
方案2：应用程序更改ab，然后事务提交，b触发器更改c
谢过
------解决方案--------------------
我的观点是方案2.理由是：（1）基于程序与数据尽可能独立的原则，能够由数据库处理的应尽量由数据库处理，应用程序负责业务逻辑；（2）将数据处理交由数据库服务器处理，也方便了系统的维护，比如b触发器更改c的逻辑发生改变，只要去修改b的触发器，而不必修改应用程序重新编译发布，大大降低了系统维护成本。
------解决方案--------------------
触发器基于事务机制，c与b可以看做是一条语句，如果宕机应该是保存事务记录，然后开启时根据事务记录以提交的继续存盘，未提交的回滚，如果在c触发时宕机应该属于未提交
------解决方案--------------------

引用:

引用:
我的观点是方案2.理由是：（1）基于程序与数据尽可能独立的原则，能够由数据库处理的应尽量由数据库处理，应用程序负责业务逻辑；（2）将数据处理交由数据库服务器处理，也方便了系统的维护，比如b触发器更改c的逻辑发生改变，只要去修改b的触发器，而不必修改应用程序重新编译发布，大大降低了系统维护成本。
如果中途出现宕机、数据库断开这些意外，数据库有相应的恢……

应用程序所提交的处理，在数据库服务器上是一个事务，b的触发器是这个事务的一部分，如果b的触发器在执行过程中发生意外，则整个事务是不会被提交的。所以说，方案2应该是安全的。
------解决方案--------------------
个人倾向于方案2，一般人手录入的记录交给程序提交，数据库已有的记录交给服务器处理。至于触发器在意外情况下的更新是否安全，这个没研究过，参考楼上2位或者其他大神解答。