为了保证数据库的完整性和一致性。非常多的时候须要运行多条sql语句才干达到想要的目的。
在一对多的数据库关系中，比方卡号类别与卡号之间的关系。假设要取消某个类别的时候，就要连同齐下的全部卡号都删除。
在现实中。注冊的时候一般都会进行充值，当我想card表里面写东西的时候，就要向recharge表里面写一条充值记录。
完毕这两个操作才算完毕这个功能的实现.
对于以上的需求。每一个功能的实现
都伴随着多条sql语句的运行。
为了解决上面的问题，一共同拥有两种解决方法。一是存储过程。二是触发器。上篇博客中已经解说了存储过程。那么这篇博客当然要来具体解释一下触发器了。
触发器：当发生某个操作之后进行的一系列操作。
数据库中除了查询之外
就仅仅有增删改三种操作了。所以触发器就分为三类：insert、delete、update三种触发器。
以下来看一下实例：
这是我创建的数据库两张表：（T_card和T_type，而且两张表设置了主键和外键约束）
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvemM0NzQyMzU5MTg=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast">
以下是我运行删除‘暂时用户’所运行的结果。
（这是由于外键约束造成的错误）
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvemM0NzQyMzU5MTg=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast">
之后我再创建delete触发器。看一下能否够实现目的。
CREATE TRIGGER delType ON T_type AFTER delete AS BEGIN declare @typeId int delete T_card where typeid in (select typeid from deleted) --从已经删除的表中 取出typeId END GO
运行结果与上述错误同样。
在来看一下sql
server中创建触发器的定义模版：
大家注意到alter了没有，insert
delete update这三种触发器都是在完毕操作之后再
运行之后的一系列sql语句。
假设这触发器的条件运行出错。那么后面的操作就都没有办法运行了。
因此。大家正在想。
假设我先删除
‘暂时用户’的卡号，在来删除卡号类别，这样错误不就没有了吗。
要找一系列操作来替代delete方法。
alter TRIGGER delType ON T_type instead of delete AS BEGIN declare @typeId int select @typeId=typeid from deleted --从打算删除的表中 取出typeId ：还没有删除 delete T_card where typeid in (select typeid from deleted) --先删除卡类别相应的卡号 delete T_type where <a target=_blank href="mailto:[email protected] ">[email protected] </a>--在删除卡号类别 END GO
之后再运行sql语句看效果：
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvemM0NzQyMzU5MTg=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast">
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvemM0NzQyMzU5MTg=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast">
达到了想要的效果。在删除了暂时用户这个类别和暂时用户的卡号。
能够使用触发器的需求：当对某张表进行增删改等操作的时候，须要对其它表进行一系列的操作。
使用触发器，能够保证数据库的完整性。存储过程和触发器的编写。能够降低程序的代码，降低难度。
同一时候也是为了降低反复代码。对于一个系统来说，假设没有使用触发器和存储过程等方法。
那么代码的编写，反复量将是非常可怕的。相反，假设设计好数据库。写好存储过程和触发器等。
在来看这个系统。那真是简单多了。
版权声明：本文博主原创文章，博客，未经同意不得转载。