Created by Wang, Jerry, last modified on Nov 12, 2015

这段代码由两段非常复杂的SQL 查询语句组成。两段语句绝大部分都相同，除了下图的四处。从clean code角度出发，这是dplication。但是由于这里用到的是OPEN SQL，无法把common的部分抽成方法，因为OPEN SQL里的JOIN不支持把table name dynamic 传进去。

就我的理解，crm_jest_和crm_jsto都是client dependent的表，因此不需要通过CLIENT SPECIFIED显式指定client。

按照SCN上的说法，指定client和不指定，对性能无任何影响。

我觉的这个IS NULL可以去掉。

ABAP help上说的很清楚：

Please note that the NULL value is inserted only for the existing records, by the time the new field is being inserted. For all new records, SPACE or the initial (default) value is inserted.

If the new field is inserted by checking the checkbox “initial values”, then the initial values (SPACE in case of characters) are automatically inserted and not the NULL values.

而且这个field的initial已经勾上了，因此唯一可能让IS NULL返回true的condition，

就是ABAP help 里提到的outer join：

但是我看了下source code里的OPEN SQL，里面的操作应该不会造成template field为NULL的结果，所以我觉得这个检查可以删除。

这个ABAP open SQL do’s and don’ts 里说

(1) 尽量避免nested select statement

(2) 尽量避免复杂的where语句，否则database optimizer没法做优化。我们这个代码里的where语句里又套了嵌套的select，应该算是complex了。

这个还是改成常量space吧：

然后I1004改成released吧：

AG3和QHD都是HANA DB了，即使我们的代码在上面跑的很快，但是也不能排除如果在客户的Non HANA DB比如max DB上跑效果如何。一个典型的例子就是ERCO的account search in my appointment，BP底层的SQL是动态生成的，在我们自己的系统上一直没有遇到过性能问题，这个incident 6月份就报了，到现在BP都没解决。

最后DB expert分析得出结论现在的SQL 语句在MaxDB下需要重写。

所以我在想我们有时间的话，能不能先考虑准备另一套方案，就是先设法把where里的nested select去掉，可以换成用多个select顺序执行的方式，最后简单测试下两个solution的性能。

我去年做联想的性能评测就是在AG3上做的：

把SQL里所有涉及到的表全部copy一个Z的出来，创建两个report，把两种solution的SQL 语句贴到report里，当然table name也要全部换成Z的

在AG3上写一个report，把每个Z表的每一条数据， 根据需要分别复制一个倍数。比如CRM_MKTPL_ATTR现在有100条，我把每条复制1000次，每次复制的时候重新生成新的guid，其他数据都不变，这样复制完后我就得到10万条数据了。

当然这样做的话要花点时间。