个人对程序员是充满无比的崇敬和敬仰的，这辈子没做程序员是我大的遗憾。他们创造这这个世界，的确是伟大的。

在程序开发的SQL 存储过程中有这样一个想法，就是我只要完成功能就可以了，的确，数据量小完成功能就好了，我可以将我的存储过程写成一个 “方法论”，来回的调用，也可以将我的存储过程，写成一部 “韩国连续剧”，或者一部日本的“贞子”。

为何这样说，因为在我阅读过的存储过程中，真的是有“贞子的”， 基本上都以完成功能为主，其他的，其他的剩下的都是“贞子”。

你见过一个存储过程，从头倒下，全部都是 insert into  select  ..case...when  when  join.... join where.....  group by  order by  

你是否见过一个存储过程中，充斥着 update ... set .....   where  xxx exist (select ...........)  

我估计你是见过的，并且在程序员的眼里, whatever ，你语句提供我这样写，我就可以这样写，而且我功能完成的不错，我有什么问题吗？

下面就是某财务软件公司设计的 “触发器”

我也希望我在别人心目中是 NICE ,KIND , be a gentleman.

但我对这样的程序设计和对数据库根本就不懂的行的设计，深表遗憾，如此设计，等待着的是客户的抱怨和甚至是愤怒。

和同事们针对此事，讨论了一番，观点一致，从逻辑的设计，到代码的形成，都只能持深表遗憾的情感和态度。因为我们的客户不是, 心情平静的，佛系的客户，当你的系统慢的要死的时候，他们必然换一张脸，回答到， 不是我的问题哟，系统太慢，我都工作不了呢？

在费劲心力后，后得到就是这样一个“回复”， 我想DEVELOPERS 的心情一定有上万只 “羊驼” 飞过。

可问题是，开发的时候，如果你想到终的结果，你还会做如下的事情吗？

1 update 语句 后面跟一堆的条件，关联表，并且在UPDATE之前就要耗时很长.

2  insert into  select  语句，后面要跟一堆的各种表的JOIN ，各种的判断，耗时很长

3  不尽量避免游标的使用，通篇的游标+ 循环（还是在内部）

4  一堆的 if else  if else ,仿佛进入了迷宫

5 在插入的端口，进行极为复杂的TRIGGER 设计

终上所述，陷入了一个怪圈，数据库的程序设计写的就像一部 “韩国 108” 集的电视剧。

那怎么避免这样的问题

1 UPDATE 就好好的UPDATE  后边别跟一堆的条件，UDPATE 一定要快，你可以将你需要的在UDPATE 后处理的判断，先进行一个select 将其格式化，变量化，等等，这并不是多难的事情，但你的客户，就不会因为系统缓慢的运行，将你推到 “悬崖”。

2 INSERT 请就好好的INSERT  INSERT INTO  在大型系统里面不应该被存在，如何处理见上

3 游标，如果实在没有办法，那就用，不频繁使用没问题，否则祈求，客户别投诉。

4  关于TRIGGER 的设计，在很多系统都被禁用，当然我们应该具体问题具体分析，但上面图上那样的ORACLE TRIGGER 设计，我真的很无语。

那存储过程里面为什么要存在临时表，原因如下

，

1 复杂的多表查询中，数据库的优化引擎在牛B ，他也有算错的时候，无论是因为统计数据的错，还是语句写法的错，复杂的查询，如果变成多个简单的查询，都是没有坏处的，那如何变成简单的查询，承接中间的结果，自然是要用临时表了。

2 临时表可以在加索引，提高查询的效率（部分数据库还有 内存表）

3既然是临时表，其中的结果集应该不是很大，如果很大那就是另外一个话题了。

所以在大型系统中，请尽量将操作DML的操作与 SELECT 的操作分开，不要insert  select  , update  select ，这样不好，也容易带来更多的问题，和复杂的锁。

以上言论只针对，SQL SERVER , ORACLE ,PG ，  --- MYSQL 不在此讨论范围