再看数据库——（3）触发器，看数据库触发器

概念：

         触发器，顾名思义，它是由事件来触发的。比如当我们对表进行操作时就会激活它执行。

       说到触发器，还要提一个关键点，那就是“保持数据完整性”。什么意思呢？比如业务需求是，当我们注销一个卡号时，把该卡的充值、上机等信息也一并删除。这时如果是一个一个操作执行，就会是：注销卡——删除卡的充值信息——删除卡的上机信息（两个删除操作不分先后）。这样做的弊端是，我们很容易把其中的一个步骤遗漏了，业务也不完整。用了触发器以后，当我们注销卡时激活触发器执行删除操作。

      用触发器的好处就是很大程度上有利于加强数据的完整性约束，符合业务规则。

类型：

DML触发器

 常用

  在DML触发器下，当我们执行增删改查操作时，触发器会自动执行。DML触发器的主要作用在于强制执行业 务规则，以及扩展Sql Server约束，默认值等。

  触发器可以弥补约束只约束同一表中数据的缺陷。

DDL触发器

主要作用：审核与规范。

我们主要用它来记录数据库的修改过程，以及限制程序员对数据库的修改，比如不允许删除某些指定表等。

登录触发器

显然，响应登录事件。

登录触发器将在登录的身份验证阶段完成之后且用户会话实际建立之前激发。因此，来自触发器内部且通常将到达用户的所有消息（例如错误消息和来自 PRINT 语句的消息）会传送到 SQL Server 错误日志。如果身份验证失败，将不激发登录触发器。

格式：

CREATE TRIGGER<触发器名称>

[BEFORE |  AFTER] <触发事件>ON <表名>

FOR EACH [ROW | STATEMENT]

[WHEN<触发条件>]

<触发动作>

注意：

 触发器与存储过程的唯一区别是触发器不能执行EXECUTE语句调用，而是在用户执行Transact-SQL语句时自动触发执行。 

 触发器本身没有过错，但由于我们的滥用会造成数据库及应用程序的维护困难。如果我们对触发器过分的依赖，势必影响数据库的结构，同时增加了维护的复杂程度。

 合理的触发器编写对设计者和编写者的要求很高，必须比较全面的分析相关业务，同时全面了解触发器工作原理。也就是说写出的触发器要求在业务上考虑全面，在技术上作到最好，才能不影响业务和性能。

 触发器来实现功能比较隐蔽，不容易被注意，给后期维护带来困难。

触发器与约束：

  触发器的主要好处在于它们可以包含使用 Transact-SQL 代码的复杂处理逻辑。因此，触发器可以支持约束的所有功能；但它在所给出的功能上并不总是最好的方法。实体完整性总应在最低级别上通过索引进行强制，这些索引或是 PRIMARY KEY 和 UNIQUE 约束的一部分，或是在约束之外独立创建的。

 CHECK 约束只能根据逻辑表达式或同一表中的另一列来验证列值。如果应用程序要求根据另一个表中的列验证列值，则必须使用触发器。约束只能通过标准的系统错误信息传递错误信息。如果应用程序要求使用（或能从中获益）自定义信息和较为复杂的错误处理，则必须使用触发器。

 如果触发器表上存在约束，则在 INSTEAD OF 触发器执行后但在 AFTER 触发器执行前检查这些约束。如果约束破坏，则回滚 INSTEAD OF 触发器操作并且不执行 AFTER 触发器。

在资料浏览器中，表的下面有。
 

1）查看表中的触发器类型:
sp_helptrigger:返回对当前数据库的指定表定义的 DML 触发器的类型。sp_helptrigger 不能用于 DDL 触发器。
示例: EXEC sp_helptrigger '表名'

2）查看触发器的有关信息:
sp_help:报告有关数据库对象（sys.sysobjects 兼容视图中列出的所有对象）、用户定义数据类型或某种数据类型的信息。
示例: EXEC sp_help '触发器名'

3）显示触发器的定义:
sp_helptext:显示规则、默认值、未加密的存储过程、用户定义函数、触发器或视图的文本。
示例: EXEC sp_helptext '触发器名'

4）查看当前库中所有的触发器:
查询脚本：SELECT * FROM Sysobjects WHERE xtype = 'TR'

5）查看当前库中所有的触发器和与之相对应的表：
查询脚本：SELECT tb2.name AS tableName,tb1.name AS triggerName FROM Sysobjects tb1 JOIN Sysobjects tb2 ON tb1.parent_obj=tb2.id WHERE tb1.type='TR'