数据库中有些数据需要同步，触发器和使用程序控制，哪个比较方便，怎么选择

比如说表A更新Aa字段时要同步表B的Ba字段，在表A绝大多数情况下的更新是更新Aa时可以用触发器，如果更新大多数情况下与Aa无关则选择使用存储过程。很好理解，因为更新于Aa无关的 *** 作，但触发器仍需执行，做无谓的消耗。

在大量并发的情况下，使用触发器是很危险的事。在并发量大的系统中触发器很影响性能的

如果非用不可,一定要注意SQL的质量

对性能的影响大小跟SQL的质量关系很大不能一概而论触发器多不是好事:

第一:一定会影响性能,若是数据量大时,每次都要触发上百上千触发器可想而知

第二:基于维护方面,不谈有多少触发器,当每修改一次触发表相应触发器就失效,符出代价可想而知

不建义多用触发器,用函数与过程代替之

分类: 电脑/网络 >> 程序设计 >> 其他编程语言

问题描述:

到底是使用触发器来简化程序,

还是程序中使用语句实现的方便啊

自我感觉好象还是比较喜欢在程序中使用语句还实现,

自己的流程性好些,知道自己该写什么对具体项目需要改动那里

方便些吧

触发器写的时候,测试真的很麻烦的!!

大家说说吧!!!

谢谢啊

解析:

触发器使用最多的地方就是维护数据的完整性，的确，它能实现的东西，在代码里大部份都能实现，但是如果涉及到多用户同时 *** 作的话，在程序里写代码当然比不上在触发器里写代码来的方便。

就拿安全库存来说吧，比如现在有2个用户同时需要出同一种产品，当前库存为100，A用户需要80，B用户需要50；在这之前他们所知道的都是一个数据，即库存为100，他们都认为可以出库，但你会发现一个问题，如果他们都出库的话，库存数明显不够，那么此时如果在程序里写代码的话，就需要进行出库前的判断并做事务处理，但是如果在触发器里写的话，那么A、B用户都可以出库（UPDATE库存），只是有一个用户会被提示库存不足，因为在触发器里已经写了如果当前要出库的数量大于库存则返回一个错误信息。

另外，如果有多个系统（如：WEB系统、桌面系统）同时用到这个数据库的话，只需要在触发器里写相应的维护代码，而不需要同时在各个系统中写同样的代码。

以上所说只是触发器的一方面应用，它也可以做一些其他“善后”工作，有待你去发掘了。

至于测试的话，可以用查询分析器来直接写语句测试。

实在对象如表格 Sequence 索引等建在本应用对应的用户表空间中 其他对象如视图 别名创建在Apps下 常见错误是新手把表建在APPS下 以后又来建别名 这个时候删除别名时会报对象不存在 而建别名的时候又报对象已存在

如果把脚本保存在文件里面 注意一个块比如一个创建视图的语句不要有空行 否则会出现如下情况 把语句拷贝到SQL Window能正常运行 用@执行文件却报错

如果要执行execute_query 注意要go_block到适当的Block 但是go_block是个受限过程 并不一定都能成功

Master detail关系

block both are database blockeach block has one item based on database displayed

在PL/SQL Develop中没有环境变量 所以如果要查询多组织的View 需要先执行设置环境变量函数:

BEGINfnd_client_info set__context( );END;

GLOBAL变量对于所有form有效（可能是同一个应用 这个尚未验证） 而不仅仅是你所开发的form变量比如Global和Parameter的初始化应该在pre form里面 在when new form instance里面初始化不行 因为when new form instance是在进入第一个导航块的第一个item之后才促发的没有属性指名Block的记录数 不过可以通过GET_BLOCK_PROPERTY(QUERY_HITS) 取得查询到的记录数hide_view并没有真正hide一个画布 只是放到最下层 所以如果上层的画布没有完全覆盖下层画布 下层的画布很可能用户还看得到 show_view则是把画布放在最上层

lov验证的时候是验证第一个可见的列 并且会把其他的返回值返回给各个Item 而不是仅仅验证而已lov的查询一般是针对第一列 但是如果我们把%放在最前面 则可以查询所有列

用Execute_query执行查询的时候 会把Copy Value From Item里面的那个Item的值自动作为查询条件 当创建记录的时候也会直接用该值初始化 而且不改变记录的状态 在更新记录的时候不知道会不会Copy过来尚未验证 Get_Item_property的时候用ENFORCE_KEY属性 但不能Set 该属性在Master detail设置的时候自动创建 删除的时候自动删除 如果不希望Copy Value From Item影响查询结果 可以在Pre Query里面把Item的值设为null

app_query reset( block_name );如果第一次调用 会把当前的DEFAULT_WHERE 然后什么都不做 以后再来调用的时候则会把第一次设置的DEFAULT_WHERE用set_block_property( SAA_HEADERS DEFAULT_WHERE )设置回来 具体请参考app_core库

When create record的时候给Item赋值不改变记录状态 Sequence 如果我们在Item的Initial Value里面赋值 那么假如用户Focus To新记录 又回到老记录 如此反复 Sequence会不断变大的

SQL Order BY的时候null值排在最后 这个一般不符合实际要求 可以这样解决ORDER BY nvl(Geography_Code chr( ))解决

Trigger顺序

pre mit块 的pre insert on insert post insert块 的pre insert on insert post insert post forms mit

Trigger顺序

when list changed在前 Validation item在后 因为Validation item是在要离开这个item的时候才促发的

Trigger顺序

pre form/when create record/pre block/when new forms instance/when validate record/on insert/post forms

当定位到主块的一个记录 会促发子块的when clear record事件和when create record事件 问题是如果主块的是新记录（未保存） 在子块的when create record里面取主块的任何东西 居然是主块的上一次获得焦点的记录的东西 连用取块的当前记录也是上一次获得焦点的记录

Trigger顺序

post changed在when validate item之前 所有的when validate事件是当forms自己验证通过之后才促发的

禁用Clear功能可以通过在Form的key clrblk里面调用app_exception disabled 其实只是用Bell覆盖默认的执行

直接放在TAB Page上的Item 和放在堆叠画布上的Item在设计时是无法 所见即所得 所以建议把所有的Item根据需要放在不同的堆叠画布上再堆到TAB Page上伪列Rownum在排序之前就已经决定 如果想得到排序后的Rownum 应当在嵌套一个Select语句 另外Where语句中的rownum只能用<或者<= 不能有>或者>=

在SQL中用Over的时候 如果整个语句没有Order by语句 最后的结果还是会排序的 规则是先按Over里面的Partition排序 在按Over里面的Order by排序 原因可能和分析函数的处理顺序有关（ ifunctions pdf有详细介绍） 先查询到数据（Join/Where/Group By/Having） 再运算分析函数（先分区 然后排序 再算Slide Windows 最后计算） 最后是Order By 另外 一个疑问 我测试到的一个结果Group By好像无法影响Partition 可是按照 ifunctions pdf的说法 应该先执行Group By的 是不是因为Group By只是在第一阶段的处理时作用在集合函数上 之后进入第二阶段的处理就没用了

同事在装 i的时候 连安装界面都没出来 而我机器可以装 后来才知道原来他的机器是P 无法正常安装

实际执行的Where条件 是我们设置DEFAULT_WHERE 再加上通过赋过值的Item

注意 APP_FIND query_range已经重载过 我们调用的时候可以不区分query_number_range或者query_date_range 观察其代码 发现也是通过给Item赋值来影响查询的 只不过是赋值的时候 可能是加上 # beeen # >=或# <= 这样导致的一个结果是 Date类型的Item长度默认是 被query_range这样一搞 长度根本不够 于是就导致诸如where REQUEST_DATE >= to_dat的错误 所以记得把字段长度加长 比如 总的来说 碰到From to的要小心长度

当修改子类的时候 会自动更改很多属性 特别是Required 一定要注意

当对块进行刷新时 会修改很多Item的属性 别以为你设置过了 Oracle就会记住 我碰到的情况是Insert Allowed等被自动改掉了！即使我的子类设置为Text_Item_Display_Only

两个变量 如果都为Null 判断还是不相等 所以必须用 a is null and a is null 所以在On lock里面的if条件 我们可以把所以不可以为空的字段都写成允许为空的形式

一般来说 系统变量是很好用的 然而有时候并非如此 比如Current_Record get_block_property( blockname Current_Record)的结果并非总是一样的 后者更加保险！特别是刚打开Form的时候 在WHEN NEW RECORD INSTANCE里面 前者是 后者是

表示一个单引号 表示两个单引号 应该是这样理解 一个单引号表示转义字符 首尾两个单引号里面的内容表示字符串

重启Application

cd $APPLCSFcd scriptscd PROD /adstpall sh apps/apps /adstrtal sh apps/apps

Trigger顺序

post query 只有在界面可见的记录才会促发 记录从不可见变为可见时促发 促发过的记录不再促发

保存的时候会引发Post Item/Record/Block事件 因为要Navigate到Form

数据库_id初始值to_number(decode(substrb(userenv( CLIENT_INFO ) ) null substrb(userenv( CLIENT_INFO ) )))

给非数据库Item赋值 new记录会变成insert（所以就不能按F 了） query/changed记录不变 new块会变成query query/changed块不变

对On lock的理解 由于先入为主的缘故 开始一直很苦恼 为什么If里面只用了一个Return Form怎么知道要锁否？后来才知道On类型的数据库触发器是替换型的 On lock也不例外 所以只要On lock不Raise什么东西出来 Form就认为是锁成功了 至于实际的锁 我们有Select……For Update来完成 至于If判断只是进行更加严格的判定

lishixinzhi/Article/program/Oracle/201311/18132

以上就是关于数据库中有些数据需要同步，触发器和使用程序控制，哪个比较方便，怎么选择全部的内容，包括:数据库中有些数据需要同步，触发器和使用程序控制，哪个比较方便，怎么选择、MS SQL SERVER2005 中触发器对性能的影响有多大、触发器的使用是否方便的思考等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！