大家好: 有张表;Table1 周报ID zid
编号 : bh
周报内容 znameTable2 周报明细 xID
周报ID zid
任务ID rID
周报日期 xdateTable3 任务ID rID
任务内容 rname
其中Table1对应多个 Table2
Table3;也对应多个 Table2现在我知道 一个 zid 如何高效的将三张表和这个zid相关联的数据全部删除啊 ?流程大概这样;先通过zid 在Table2中找任务ID(0个或多个);然后通过任务ID删除Table3;
成功后在回来根据zid 删除Table2 ;然后删除Table1;怎样做效率高呢?请教高手;我刚开始的想法是这样;delete Table3 where rID in(Select rID from Table2 where zid=(Select zid from Table1 where bh="001" ))
这样太慢了吧
编号 : bh
周报内容 znameTable2 周报明细 xID
周报ID zid
任务ID rID
周报日期 xdateTable3 任务ID rID
任务内容 rname
其中Table1对应多个 Table2
Table3;也对应多个 Table2现在我知道 一个 zid 如何高效的将三张表和这个zid相关联的数据全部删除啊 ?流程大概这样;先通过zid 在Table2中找任务ID(0个或多个);然后通过任务ID删除Table3;
成功后在回来根据zid 删除Table2 ;然后删除Table1;怎样做效率高呢?请教高手;我刚开始的想法是这样;delete Table3 where rID in(Select rID from Table2 where zid=(Select zid from Table1 where bh="001" ))
这样太慢了吧
delete Table3 t3
where exists(Select null from Table2 t2
where t2.rID=t3.rID and zid=(Select zid from Table1 where bh="001" ))
楼主是想让大家帮着,用一个SQL搞定3张表的删除? 还是,只是针对这一张表的删除SQL,进行优化?
n number:=0;
begin
for i in (select b.zid,b.rid from table1 a,table3 c,table2 b where a.zid=b.zid and c.rid=b.rid)
loop
delete from table1 where zid=i.zid;
delete from table3 where rid=i.rid;
delete from table2 where zid=i.zid;
n:=n+1;
if mod(n,1000)=0 then
commit;
end if;
end loop;
end;
-- *1) 存储过程帮助在数据库层聚集T-SQL代码。嵌入即席SQL的网站或应用程序在应用环境下很难修改,当即席SQL嵌入在应用程序内的时候,你可能会花费太多时间试图找到和调试嵌入的SQL。
-- 一旦找到了bug,你可能就需要重新编译可执行程序,引起不必要的应用程序临时停止或痛苦的应用程序部署。如果把T-SQL集中到存储过程中去,
-- 你就只需要集中在一个地方来查询SQL代码或SQL批处理。如果你能正确地为代码建立文档并对代码标准化,存储过程就会提升整个应用程序的可支持性。
-- *2) 存储过程帮助大的即席查询减少网络流量。编写应用程序调用而不是500行的SQL调用来执行存储过程,对网络以及应用程序的性能有正面影响,特别是当调用在一分钟内重复数千次时。
-- *3) 存储过程促进代码的可利用性。例如,如果你的网站应用程序使用一个下拉菜单来包含一组城市,并且这个下拉菜单用于很多网页,
-- 你可以在每个页面调用存储过程而不是在多个地方嵌入相同的SQL。
-- *4) 存储过程淡化数据获取的方法。如果你修改了提供源数据的基本表,存储过程(和视图相似)能让应用程序对这个修改透明。这样就不需要修改应用程序底层的代码就能修改。
-- 你可以把老的表换成新的,而且只要同样的列和数据类型返回给应用程序,则应用程序完全不知情。
-- *5) 与视图不同,存储过程可以利用流控制技术、临时表、表变量等。
-- *6) 存储过程对查询响应时间的影响比较稳定。如果你使用大量的即席查询,可能会注意到有时候从查询中返回结果所花的时间变化很大。
-- 这可能由诸如对表(锁)的并发活动或者资源问题(内存、CPU)等外部因素引起的。从另外一面来说,即席查询可能执行得不稳定,因为SQL Server有时候会选择效率较低的执行计划。
-- 而存储过程提供了更可靠的查询计划缓存,因此可以重用。注意到,这里我使用的是“可靠”这个单词,而不是“快速”。即席查询有时候确实比存储过程执行得更好,
-- 但是它完全依赖执行计划被缓存的环境(“被发觉”的参数),以及看你怎么测试、调优以及实现代码了。
增加主外键约束和添加触发器一样 估计楼主也不想用这种方式
那就只能按部就班的一层一层查询了
不过把in换成exists可以稍微提高一点效率 不过 肯定还是先从表一查到表二 再找表三的 没有好的办法