<Oracle优化新常态>第一章
《Oracle优化新常态》第二章强拆（1）
《Oracle优化新常态》第二章强拆（2）
<Oracle优化新常态> 第三章 三大配置
<Oracle优化新常态>第四章 分库分表
<Oracle优化新常态> 第五章 急诊法
<Oracle优化新常态> 第六章 SQL优化大法
第一禁止 禁止外键
第二禁止 禁止视图
第三禁止 禁止触发器
第四禁止 禁止存储过程
第五禁止 禁止JOB
这五大禁止会带来很多性能隐患的，其中触发器就是特例，视图也会影响性能的，你说可以做成物化视图。
自从应用程序从C/S架构发展到B/S架构，然后在是水平扩展成多机器分布式集群架构。而以上的外键，视图，触发器以及存储过程都是C/S架构中的数据库为了实现企业业务逻辑的工具。以前企业和工厂数据库服务器都采用的是小型机器，比如如今的AIX操作系统必须运行在IBM的小型机上。而ORACLE+AIX+小型机是标准搭配。如今的ORACLE EBS系统依旧运行上面平台中。以前个人电脑性能不咋地，什么586,686，奔腾1-5估计你都没有听说过，都是单核CPU。所以当时就把大量的计算工作和业务逻辑也放在了数据库服务器上跑。
如今的WEB，云化的B/S架构，已经把业务逻辑移到了 TOMCAT容器或者是IIS上运行。使用的编程语言要么JAVA，要么是C#.NET。而数据库就充当数据存储的角色。数据对象就是表和索引，而对它们的操作就是SQL。除了这三样外就别无其它了。
曾经面试被问到业务逻辑放在哪端？你怎么看待存储过程的？当初经验缺乏，不知道如何回答。虽然后来想了下，觉得业务逻辑放在JAVA层，而存储过程只处理数据逻辑。也就是说存储过程一点都不涉及业务逻辑，只是GROUP BY WHERE SUM 掉大量的数据，返回少量的数据给应用层。虽然一直觉得这是个完美的方案，各就其位，各尽所长，充分发挥各自的优点。然而现在想起这方案比较理想，你无法让开发人员又写JAVA中的业务逻辑，还要让他们写存储过程。那开发人员会无法区分业务逻辑写在哪里去了，或许那个实现方便，快捷就使用谁。或许两边都使用下，这样来业务就被拆分在两端了。
视图也是一段SQL代码，当初是为了屏蔽低下某些表给某些人看，或者是公共一段代码作为共享SQL。既然是SQL必然是业务逻辑的实现体，所以也要移植到应用层里去。
外键和触发器 如今JAVA开发人员已经取得了认识不在数据库端实现了。
关于JOB的禁止， JOB JAVA应用开发已经实现定时调度的功能，并且调度何时调度都是业务逻辑的考虑。
OK ！！ 我小仙并没有说真的在数据库上禁止这五个东西，而是说禁止开发人员去使用它们。这五个东西专属我们DBA的，我们DBA就可以使用这五个东西。因为我们不会把业务逻辑写在存储过程，视图里面啊！