sql触发器与约束，存储过程的比较，及其触发器在综合交易--变更付费关系中的使用的设想

比较触发器与约束
  约束和触发器在特殊情况下各有优势。触发器的主要好处在于它们可以包含使用 Transact-SQL 代码的复杂处理逻辑。因此，触发器可以支持约束的所有功能；但它在所给出的功能上并不总是最好的方法。
  实体完整性总应在最低级别上通过索引进行强制，这些索引或是 PRIMARY KEY 和 UNIQUE 约束的一部分，或是在约束之外独立创建的。假设功能可以满足应用程序的功能需求，域完整性应通过 CHECK 约束进行强制，而引用完整性 (RI) 则应通过 FOREIGN KEY 约束进行强制。
  在约束所支持的功能无法满足应用程序的功能要求时，触发器就极为有用。例如：
  除非 REFERENCES 子句定义了级联引用操作，否则 FOREIGN KEY 约束只能以与另一列中的值完全匹配的值来验证列值。
  CHECK 约束只能根据逻辑表达式或同一表中的另一列来验证列值。如果应用程序要求根据另一个表中的列验证列值，则必须使用触发器。触发器可以查询其他表，而且可以包含复杂的 SQL 语句。它们主要用于强制服从复杂的业务规则或要求。例如，您可以根据客户当前的帐户状态，控制是否允许插入新订单。 
  约束只能通过标准的系统错误信息传递错误信息。如果应用程序要求使用（或能从中获益）自定义信息和较为复杂的错误处理，则必须使用触发器。
  触发器可通过数据库中的相关表实现级联更改；不过，通过级联引用完整性约束可以更有效地执行这些更改。
  触发器可以禁止或回滚违反引用完整性的更改，从而取消所尝试的数据修改。当更改外键且新值与主键不匹配时，此类触发器就可能发生作用。例如，可以在 titleauthor.title_id 上创建一个插入触发器，使它在新值与 titles.title_id 中的某个值不匹配时回滚一个插入。不过，通常使用 FOREIGN KEY 来达到这个目的。
  如果触发器表上存在约束，则在 INSTEAD OF 触发器执行后但在 AFTER 触发器执行前检查这些约束。如果约束破坏，则回滚 INSTEAD OF 触发器操作并且不执行 AFTER 触发器。

比较触发器与存储过程：

语法限制：

存储过程中：commit，savepoint，and rollback are allowed within the proceder body,
触发器:commit，savepoint，and rollback are not allowed within the trigger body,

-----------------

触发器的优点如下:
1,触发器可通过数据库中的相关表实现级联更改;
2,触发器可以强制比用CHECK约束定义的约束更为复杂的约束.
3,与CHECK约束不同,触发器可以应用其他表中的列.
4,触发器也可以评估数据修改前后的表状态,并根据其差异采取对策.
5,一个表中的多个同类触发器(insert,update 或delete)允许采取多个不同的对策以响应同一个修改语句.

应用：

触发器可以解决高级形式的业务规则或复杂行为限制以及实现定制记录等一些方面的问题。

-----------------------------------------------

实际应用：

具体业务-------变更付费关系:

需要修改的数据库表：

依据user_no和pay_no

判断满足变更条件后做以下操作：
--写日志表：通过新增流水来做日志，
log_pay_raltion:记录修改前状态 ；记录操作部门，操作时间等。是由那中业务操作引起的修改：serv_code
--修改生命周期表：
life_pay_raltion ：修改一条,将旧的记录失效掉
/*日志表和生命周期表通过流水service_sn 来关联。*/
--修改前先写日志表：
log_pay_raltion:记录修改后状态
--修改生命周期表：life_pay_raltion
加一条：增加新的记录
--修改付费关系表
pay_relationt :修改user_no 和 pay_no 之间的关系。

这些操作是否通过触发器来调用会好一些。

具体操作如下：建立一个付费关系变更的视图，所有关于用户和帐户的操作都可以基于这个视图操作，业务实现更清晰。

程序员只需要知道修改对应的视图，不需要知道底层的数据表是如何设计的。