再看数据库——（3）触发器
概念：
触发器，顾名思义，它是由事件来触发的。
比方当我们对表进行操作时就会激活它运行。
说到触发器。还要提一个关键点，那就是“保持数据完整性”。什么意思呢？比方业务需求是，当我们注销一个卡号时，把该卡的充值、上机等信息也一并删除。这时假设是一个一个操作运行，就会是：注销卡——删除卡的充值信息——删除卡的上机信息（两个删除操作不分先后）。
这样做的弊端是，我们非常easy把当中的一个步骤遗漏了，业务也不完整。用了触发器以后。当我们注销卡时激活触发器运行删除操作。
用触发器的优点就是非常大程度上有利于加强数据的完整性约束。符合业务规则。
类型：
DML触发器
经常使用
在DML触发器下。当我们运行增删改查操作时，触发器会自己主动运行。DML触发器的主要作用在于强制运行业 务规则，以及扩展Sql Server约束，默认值等。
触发器能够弥补约束仅仅约束同一表中数据的缺陷。
DDL触发器
主要作用：审核与规范。
我们主要用它来记录数据库的改动过程，以及限制程序猿对数据库的改动，比方不同意删除某些指定表等。
登录触发器
显然，响应登录事件。
登录触发器将在登录的身份验证阶段完毕之后且用户会话实际建立之前激发。因此。来自触发器内部且通常将到达用户的全部消息（比如错误消息和来自
PRINT 语句的消息）会传送到 SQL Server 错误日志。假设身份验证失败，将不激发登录触发器。
格式：
CREATE TRIGGER<触发器名称>
[BEFORE | AFTER] <触发事件>ON<表名>
FOR EACH [ROW | STATEMENT]
[WHEN<触发条件>]
<触发动作>
注意：
触发器与存储过程的唯一差别是触发器不能运行EXECUTE语句调用。而是在用户运行Transact-SQL语句时自己主动触发运行。
触发器本身没有过错。但因为我们的滥用会造成数据库及应用程序的维护困难。如果我们对触发器过分的依赖，势必影响数据库的结构，同一时候添加了维护的复杂程度。
合理的触发器编写对设计者和编写者的要求非常高，必须比較全面的分析相关业务。同一时候全面了解触发器工作原理。
也就是说写出的触发器要求在业务上考虑全面。在技术上作到最好。才干不影响业务和性能。
触发器来实现功能比較隐蔽，不easy被注意，给后期维护带来困难。
触发器与约束：
触发器的主要优点在于它们能够包括使用 Transact-SQL 代码的复杂处理逻辑。因此，触发器能够支持约束的全部功能；但它在所给出的功能上并不总是最好的方法。实体完整性总应在最低级别上通过索引进行强制，这些索引或是
PRIMARY KEY 和 UNIQUE 约束的一部分，或是在约束之外独立创建的。
CHECK 约束仅仅能依据逻辑表达式或同一表中的还有一列来验证列值。假设应用程序要求依据还有一个表中的列验证列值，则必须使用触发器。
约束仅仅能通过标准的系统错误信息传递错误信息。假设应用程序要求使用（或能从中获益）自己定义信息和较为复杂的错误处理，则必须使用触发器。
假设触发器表上存在约束，则在
INSTEAD OF 触发器运行后但在 AFTER 触发器运行前检查这些约束。假设约束破坏，则回滚 INSTEAD OF 触发器操作而且不运行 AFTER 触发器。
系列博客推荐：
