一个programmer关于Oracle SQL的学习小结与思考
http://www.javaeye.com/topic/366991#
作为一个开发人员，开始认真系统学习
Oracle SQL也只有月余，之前的
SQL知
识仅仅是项目里面用到什么就去看什么，简单说就是
Read The Fxxking Guide。在系统学习
Oracle
SQL之前，俺的想法就是“按照需求完成功能，剩下的交给
DBA来处理”。这个想法从整体来看显而易见是错误
的，但若分割成两个独立的分句“按照需求完成功能”与“剩下的交给
DBA来处理”却又是正确的。接下来详细阐述我的观点。
你的问题是什么？
这个问题应该无时无刻地回响在我们的脑海中。我们必须清晰地了解我们面对的问题是什么？否则就会演变成一句老话“进去的是垃圾，出来的还是垃圾！”。而
SQL调
优的最牛的境界就是不需要继续运行那个
SQL（因为无论如何调优，那条
SQL语句仍然会占用资源，
而不运行该
SQL，则它的
cost就是零，没有比这个更牛
X的了），要
做到这一步的前提，显然是充分理解所需处理的问题。不知道问题的来龙去脉，不知道写该
SQL的目的，或者是不清晰明白“我的问
题是什么”，写出来的
SQL的也是蹩脚
SQL，也是被无数
DBA深恶的
SQL，
也很可能成为应用的性能
murder。也是基于此原因，开发人员也应该熟练掌握基本
SQL语法，基本的调优原则，不要写出有明显性能问题的
SQL
语句。并且这是开发人员应该做的，且必须做到的，因为我们才是切实明白或者说更应该理解我们所需面对的问题的人,我们
才是对后续SQL调优的最佳人选
，而且
DBA
很难通过
SQL
语
句去了解开发人员写该
SQL
的目的，这一点就剥夺了
DBA
从
本质上提升性能的机会，留给他们的只能是无尽的猜测，
hint
，运气好的话，还能找到那个被诅咒的
开发人员问问写那条
SQL
的原因何在。当然，我由衷的希望这个
DBA
没
有带刀 ：）
在明确了“问题是什么？”后，进一步就是按照正确的理解去实现
SQL。开发人员应该“按照需求完成功能”，不能完成功能的
SQL都
是垃圾，不论其性能多么优异，写得多么漂亮。就如，一条
SQL本该返回
100条数据，而实际却只返
回了
99条，那么哪怕是换一种写法能返回
100条数据，但是性能比目前的返回
99条
数据的
SQL要差很多，那么我们也应该选择能完成功能的
SQL，
99不
是
100，用户要的是
100，而不是
相关文档：
select count(*) from t1;
这句话比较简单，但很有玄机！对这句话运行的理解，反映了你对数据库的理解深度！
建立实验的大表他t1
SQL> conn scott/tiger
已连接。
SQL> drop table t1 purge;
表已删除。
SQL> create table t1 as select * from emp where 0=9;
表已创建。
SQL> insert into t1 sele ......
1.判断一个临时表是否存在
if exists (select * from tempdb.dbo.sysobjects where id = object_id(N'tempdb..#tempcitys') and type='U')
drop table #tempcitys
注意tempdb后面是两个. 不是一个的
---临时表
if exists(select * from tempdb..sysobjects where name like &lsqu ......
jsp连接sql server2005
（经测试连接成功）
接触Java或者JSP，难免会使用到数据库
SQL Server
2000/2005（我使用2005标准版[9.0.3054]测试），经过自己的搜索和研究，使用JDBC连接SQL
Server成功，特此整理方法（使用Eclipse 3.2）如下。
准备工作
首先，操作系统
中安装好SQL Server
2000/2005，� ......
SQL调优 之 连接方式
Join是一种试图将两个表结合在一起的谓词，一次只能连接2个表，表连接也可以被称为表关联。在后面的叙述中，使用”row source”来代替”表”，因为使用row source更严谨一些，并且将参与连接的2个row source分别称为row source1和row source 2。Join过程的各个步骤经常是串行操作 ......
