我们是不是还必定应当利用存储历程(三)

为了在某种程序上弥补这一缺陷，许多SQL命令都有一个DELAY_KEY_WRITE项。这个选项的作用是暂时制止MySQL在该命令每插入一条新记录和每修改一条现有之后立刻对索引进行刷新，对索引的刷新将等到全部记录插入/修改完毕之后再进行。传言3：存储历程要比SQL代码加倍平安

在实行任何SQL语句之前，数据库引擎城市实验婚配挪用者供应的论证信息和所哀求资本的会见权限。依据婚配了局，引擎决意是不是实行该SQL代码。

如许看来，从平安角度存储历程明显要比一般的SQL代码更有上风。为何会如许呢？由于存储历程可看作是数据库中的一个实体，能够由数据库办理员DBA显式给其平安需求，即借助数据库的平安基本举措措施来回护存储历程，由于存储历程原本就是属于数据库资本的一部分。

而一般的SQL语句就是个字符串，将静态地发送给数据库实行，因而数据库引擎不克不及将其当做外部资本，也没法把权限联系关系在它下面。权限仅能使用在SQL将利用的数据表或视图上，这明显属于另外一个条理的平安。因而，操纵全体上的平安性要交给挪用者卖力包管。

年夜多半人应当对下面的剖析没有疑义，关头是经由过程下面的剖析能够发生两个相反的结论，且这取决于人们的立场，妙技和对待成绩的角度。

若你更熟习数据库，那末一般会停在这里并得出结论：存储历程是计划数据会见层中必不成少的。

不外问问本人这3个成绩：存储过程当中将要实行哪些范例的操纵？这些操纵都要带有甚么样的署名？在年夜型体系中你实践必要几个存储历程？

在我们看来，若你以为存储过程当中必不成少的，那末也会不盲目地在存储过程当中完成（最少一部分）营业逻辑，但这一点是我们倡始应当勉力制止的。稍后将持续会商这个成绩，这里我们先来完成对平安性的会商。

平安性是个横切的存眷点，应当在从体现层到数据库的各层中都有处置。明天，基于脚色的平安是最天真且无效的做法。在基于脚色的平安模子中，我们对平安性有着两重的包管，第一重是两头层中利用基于脚色的平安，第二重是数据库引擎中的声明平安。且这一点和利用静态SQL代码或存储历程其实不相干。

若利用存储历程来完成体系的平安性需求，则会不盲目地将数据库开辟职员和别的开辟职员分别开来。而后面曾提到过，平安性应当是个团队的事情。因些我们就回到了那些偏向于利用存储历程的说法中———“若想包管平安的话，就要利用存储历程”。不外实践上，若你真的想要包管平安，则必需保持将存储历程作为必不成少的功效的设法。之以是如许说，并非由于存储历程有甚么欠好，而是由于若将存储历程作为全部体系的中心，那末一定会让人作出欠好的计划决意———从平安角度思索。你仍旧可使用存储历程，不外不要再说是出于平安性思索，也不要用存储历程来完成逻辑。那存储历程另有甚么用呢？一样平常也仅用在处置数据表会见上。

传言4：存储历程可让SQL代码加倍不乱且不容易改动

软件范畴中有良多让人废寝忘食寻求的幻想方针，个中一个就是使编程能够不遭到数据库模子的变更影响。若某个数据库表产生了变更，会不会影响到其相干的代码吗？这是一个罕见的疑虑。不外准确的谜底仍旧不是利用存储历程。

若将SQL命令放在数据会见层中（就像我们在手工数据会见层中的完成一样），就会在代码和物料数据模子之间创建依附。若数据模子有所变更，就必要更新代码。不外我们能够说，此类依附仅仅存在于数据映照器类中，且SQL语句也是作为公有成员声明的。因而固然存在依附，不外局限十分小。若数据表产生了变更，必需更新数据映照类。不外这也就是一切必要的修正，仅限于数据会见层外部。

利用存储历程是否是真的能让代码与数据模子的变更完整自力呢？若数据模子产生了变更，那末要完成两种更新：修正SQL代码和修正挪用者代码。实在，我们并没有看到在数据映照器类中挪用存储历程和一般SQL语句有甚么区分。

在我们看来，存储历程可让数据会见代码加倍不乱的说法仅仅是个传言，这个传言是之前的那种体系计划体例的天然产品，即数据库开辟职员和其他开辟职员基础没有相同交换。

若你真想完整不依附于物理数据模子，那末应当选择范畴驱动计划，并将数据库计划成一个复杂的耐久化层。数据会见代码将由O/R映照层卖力以参数化查询（乃至是以存储历程）的体例静态天生。

(本文摘自：Microsoft.NET企业级使用架构计划)因此我们的方案中要构造这种逆操作。Event_type增加一种FlashBACK_EVENT。这类操作形式与Query_Event相同，都是简单的SQL语句，只是包含了将数据恢复的操作。