最近两个月的培训和学习，每天伴随的内容都有编写SQL，说到EBS SQL，也有了一点自己编写的心得：

（1）       确定待查询字段

    可能这个看起来会比较容易，不过如果找错，则会对后面编写SQL造成非常不好的影响，例如：在PO模块中找quote number，如果没有确定字段，误以为是哪个ID或者其他，而没有看到是弹性域中的segment1，则在后面编写SQL的过程中会出现大量的问题。

而确定字段的方法有很大一部分是依赖经验和对于EBS表结构的掌握程度，除此以外，一般在FORM中，我们都可以首先查询出一条或者多条记录，使用 Help->About This Record：

从而查到该FORM是基于哪个视图创建的，从视图入手，通过select * from 该视图，并添加合适的WHERE语句，找出界面上的字段分别对应视图中的哪些字段，进而分析该视图，就可以将各个字段找出来。

除了这个，还有个技巧，我想做过FORM的人都应该知道，FORM中的数据块是基于数据库对象（一般是表或视图，视图居多）进行创建的，而数据块又对应着界面上的实际的字段，这样就可以通过Help->Diagnostics->Examine

进行查找该字段对应数据块中的哪个数据项，再经过推测有时也会有意想不到的收获。

（2）       了解必要的业务逻辑，猜测WHERE条件

由于WHERE条件是SQL中的重要部分，因此准确快速的写出WHERE条件也是SQL编写质量或好坏的重要标准。而在EBS中，在SQL编写前如果能对该模块的业务有些必要的认识和了解，这样就可以通过业务逻辑来猜测各个部分之间的关系，对于WHERE条件的确定是非常有帮助的。还是以PO模块为例，如果能将Header,Line,Shipment的关系理清楚，在结合上步找到的视图中的关系，准确快速地找到WHERE条件不是难事。

另外，对于业务逻辑的了解还可以帮助我们更好地分析在哪需要用到外连接。

（3）       找表

    这个应该是整个SQL的核心也是最困难的地方，其实我做得也非常不好，经常会浪费很多的时间，而且还未必能找得准确，所以只能简单说说自己的想法：如果能像2中描述的那样，对于待编写SQL的模块的业务进行熟悉，就应该能确定该模块功能之间的关系，从这些关系入手，分析牵扯到的表有哪些，最好的办法就是多查查表中的字段，再结合1中的视图进行分析，这样大部分的表都可以确定。而在找数据表的过程中，需要根据业务目的明确该SQL的主表是哪个，不可以偏离主表，若没有把握好主表，有时候甚至会造成各种表乱连的情况，是非常要不得的。

   以上仅为个人意见，若有不同意见，欢迎留言讨论。

发表于 @ 2008年09月24日 14:15:00|评论(loading...)|收藏